Gtk绝对/相对/或"否"路径(Windows)

时间:2016-11-20 19:54:21

标签: gtk gtk2

使用Gtk +,我们会通过gtk_image_new_from_file()将一些图标引入到应用中。我们发现,如果图标文件直接在应用程序目录中,那么这一切都适用于"没有路径",例如。

FString255 = "Icon_Charts.png"
IconImage_Ptr = gtk_image_new_from_file( Trim(FString255)//c_Null_Char )

然而,当我们试图将图标移动到子目录时(多么令人惊讶,称为"图标"),我们无法让Gtk识别png。我们尝试了使用绝对和相对变化我们可以想到的每个排列(例如使用"。\"使用" ./",使用"双斜线",使用" C:..... \ Icons ..."等等......)没有快乐。

是否有人知道Gtk期望的相对路径的语法,例如类似的东西:

FString255 = ".\Icons\Icon_Charts.png"

???

或许有什么东西"特别"关于gtk_image_new_from_file(),也许它只能接受"没有路径"文件名?

我们感觉它一定是超级简单的东西,我们错过了。

2 个答案:

答案 0 :(得分:0)

为避免任何非显而易见的行为,您应始终使用绝对路径。

GLib提供g_win32_get_package_installation_directory_of_module()函数以允许获取当前项目的路径(假设标准目录布局)。例如:

char *path, *package_dir;

package_dir = g_win32_get_package_installation_directory_of_module (NULL);
g_assert (package_dir != NULL);
path = g_build_filename (package_dir, "Icons", "Icon_Charts.png", NULL);

g_free (package_dir);

答案 1 :(得分:0)

好的,怀疑它,我们感到非常愚蠢和尴尬。我们的OP怀疑:

“我们感觉它必须是我们错过的超级简单的东西。”

......好吧,那是: - (。

在“实际回答”之前,如果真正的问题不完全是其他问题,那么TingPing的回答将是可能的。然而,即便如此,如果我们要走这条路,我们会使用类似的东西(保持我们提交的“与Fortran一致”的OP):

Temp_cPtr = g_get_current_dir_utf8 ()
!
If( c_Associated(Temp_cPtr) ) Then
    !
    !
    n = c_StrLen( Temp_cPtr )
    !
    FString255Path = ""
    !
    Call C_F_String( Temp_cPtr, FString255Path(1:n) )
    !
End if
!
!
FString255 = FString255Path(1:n)//"\Icons\Icon_Charts.png"
IconImage_Ptr(j) = gtk_image_new_from_file( Trim(FString255)//c_Null_Char )

或将“\ Icons”设置为var并在开始时调整路径变量,例如

FString255Path = FString255Path(1:n)//"\Icons\"
FString255 = Trim(FString255Path)//"Icon_Charts.png"

...是的,我们也可以使用Allocatable字符串,这就是我们在这里使用固定len字符串的原因。

在这种情况下,通常的“简单”事实确实起作用,例如,正如最初想的那样,所需的相对路径方法确实如此:

FString255 = ".\Icons\Icon_Charts.png"
IconImage_Ptr(j) = gtk_image_new_from_file( Trim(FString255)//c_Null_Char )

好的,现在是“实际答案”,还有我们的“愚蠢纪念碑”;实际上这个Gtk应用程序非常庞大,前端的某些部分是用Glade和“builder”创建的,而其他部分则是用代码显式编写的。 Glade / builder位以及显式代码位都使用了一些相同的图标。碰巧的是,我们在开始时使用了正确的(相对)路径...不幸的是,我们在Glade / builder位生成的GUI的一部分中查找结果,当然它们有自己独立的加载图标的机制(即使在“代码”中重复使用相同的图标),因此没有任何摆弄“代码/路径”会产生任何差异。

......这对我们来说是一个“灌木联盟”的错误,如果整个问题/帖子被删除会感觉更好......但也许我们应该“尊重我们对愚蠢的纪念碑”:-)。

...我们为浪费任何人的时间道歉。