date:20190303

Re: Finding .desktop file and application info

2019-03-03 Thread Osmo Antero via gtk-app-devel-list

Btw:
Totem (GNOME `s Video Player) has very similar problem.
It «lies» about its .desktop file name. It says "totem" instead of
"org.gnome.Totem".
My app asks for it via DBus/MPRIS2 and gets wrong data.

$ locate -i totem | grep ".desktop"
/usr/share/applications/org.gnome.Totem.desktop

It is hard to co-operate on the Desktop when apps do stick to the damn
rules.

Boa noite,
  Moma

Osmo Antero  escreveu no dia domingo, 3/03/2019 à(s)
21:05:

>
> Osmo Antero
> 20:53 (há 11 minutos)
> para tito-wolit
>
> Hello Tito,
> Muito obrigado.
> Thank you, the call with "kde4-" worked fine.
>
> However,  the "DesktopEntry" value from Amarok/DBus does not contain the
> "kde4" part.
> Please see the MRIS2-spec:
> https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry
>
> My application cannot guess that it must include the "kde4" to get a valid
> .desktop file.
> I think g_desktop_app_info_new() should also browse all sub-directories,
> but is does not.
>
> One possible solutions is this:
> The application should find the real location and path of
> "org.kde.amarok.desktop".
> The "locate" command does the same thing.
> My app cannot call "locate" directly because it depends on "sudo
> updatedb".
> I will write my own routine that dives to usr/share/applications/ and its
> sub folders.
> This is my best shot !
>
> Then the app can call:
> GDesktopAppInfo *g_desktop_app_info_new_from_filename(const char
> *filename);
>
> My very old app is this: (the latest is v3.0.2)
> https://launchpad.net/~audio-recorder
>
> Thanks,
> Obrigado e boa noite.
> // Moma
> Portugal
>
> tito-wolit via gtk-app-devel-list  escreveu
> no dia domingo, 3/03/2019 à(s) 19:42:
>
>>
>>
>> On 3/3/19 6:36 PM, Osmo Antero via gtk-app-devel-list wrote:
>> > Hello,
>> > I have an application that uses g_desktop_app_info_new() function to
>> > find GDesktopAppInfo.
>> >
>> > I just wonder why the g_desktop_app_info_new() FAILS to find the
>> > GDesktopAppInfo if the .desktop file is in a sub directory
>> > under usr/share/applications/.
>> >
>> > So this fails:
>> > GDesktopAppInfo *app_info =
>> g_desktop_app_info_new("org.kde.amarok.desktop")
>>
>> hi,
>> try:
>>
>> GDesktopAppInfo *app_info =
>> g_desktop_app_info_new("kde4-org.kde.amarok.desktop")
>>
>> ciao,
>> Tito
>>
>> > If the "org.kde.amarok.desktop" file is located in:
>> > /usr/share/applications/kde4/org.kde.amarok.desktop
>> > This is the default location of Amarok player.
>> > ---
>> > Then I move the file "org.kde.amarok.desktop"  to
>> /usr/share/applications/.
>> >
>> > $ sudo mv /usr/share/applications/kde4/org.kde.amarok.desktop
>> > /usr/share/applications/org.kde.amarok.desktop
>> >
>> > $ sudo updatedb
>> > $ locate org.kde.amarok.desktop
>> > /usr/share/applications/org.kde.amarok.desktop
>> >
>> > Now the call succeeds. It returns GDesktopAppInfo structure.
>> > GDesktopAppInfo *app_info =
>> g_desktop_app_info_new("org.kde.amarok.desktop")
>> >
>> > Something is wrong, because the manual says that the desktop file can
>> stay
>> > in a sub directory:
>> >
>> > 
>> > g_desktop_app_info_new ()
>> > GDesktopAppInfo * g_desktop_app_info_new (const char *desktop_id);
>> >
>> > Creates a new GDesktopAppInfo based on a desktop file id.
>> >
>> > A desktop file id is the basename of the desktop file, including the
>> > .desktop extension. GIO is looking for a desktop file with this name in
>> the
>> > applications subdirectories of the XDG data directories (i.e. the
>> > directories specified in the XDG_DATA_HOME and XDG_DATA_DIRS environment
>> > variables). GIO also supports the prefix-to-subdirectory mapping that is
>> > described in the Menu Spec (i.e. a desktop id of kde-foo.desktop will
>> > match/usr/share/applications/kde/foo.desktop).
>> > 
>> >
>> > Just for info:
>> > My application gets the "org.kde.amarok.desktop" name from Amarok via
>> the
>> > MPRIS2 DBus-interface.  Please see "DesktopEntry" of
>> >
>> https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry
>> >
>> > Please educate me.
>> >
>> > Kindly
>> >Osmo Moma Antero
>> >Portugal
>> >
>> ___
>> gtk-app-devel-list mailing list
>> gtk-app-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>>
>
>
> --
> Sent from my PC, laptop or phone with Ubuntu-Linux.
>


-- 
Sent from my PC, laptop or phone with Ubuntu-Linux.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Finding .desktop file and application info

2019-03-03 Thread Osmo Antero via gtk-app-devel-list

Osmo Antero
20:53 (há 11 minutos)
para tito-wolit

Hello Tito,
Muito obrigado.
Thank you, the call with "kde4-" worked fine.

However,  the "DesktopEntry" value from Amarok/DBus does not contain the
"kde4" part.
Please see the MRIS2-spec:
https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry

My application cannot guess that it must include the "kde4" to get a valid
.desktop file.
I think g_desktop_app_info_new() should also browse all sub-directories,
but is does not.

One possible solutions is this:
The application should find the real location and path of
"org.kde.amarok.desktop".
The "locate" command does the same thing.
My app cannot call "locate" directly because it depends on "sudo updatedb".
I will write my own routine that dives to usr/share/applications/ and its
sub folders.
This is my best shot !

Then the app can call:
GDesktopAppInfo *g_desktop_app_info_new_from_filename(const char *filename);

My very old app is this: (the latest is v3.0.2)
https://launchpad.net/~audio-recorder

Thanks,
Obrigado e boa noite.
// Moma
Portugal

tito-wolit via gtk-app-devel-list  escreveu
no dia domingo, 3/03/2019 à(s) 19:42:

>
>
> On 3/3/19 6:36 PM, Osmo Antero via gtk-app-devel-list wrote:
> > Hello,
> > I have an application that uses g_desktop_app_info_new() function to
> > find GDesktopAppInfo.
> >
> > I just wonder why the g_desktop_app_info_new() FAILS to find the
> > GDesktopAppInfo if the .desktop file is in a sub directory
> > under usr/share/applications/.
> >
> > So this fails:
> > GDesktopAppInfo *app_info =
> g_desktop_app_info_new("org.kde.amarok.desktop")
>
> hi,
> try:
>
> GDesktopAppInfo *app_info =
> g_desktop_app_info_new("kde4-org.kde.amarok.desktop")
>
> ciao,
> Tito
>
> > If the "org.kde.amarok.desktop" file is located in:
> > /usr/share/applications/kde4/org.kde.amarok.desktop
> > This is the default location of Amarok player.
> > ---
> > Then I move the file "org.kde.amarok.desktop"  to
> /usr/share/applications/.
> >
> > $ sudo mv /usr/share/applications/kde4/org.kde.amarok.desktop
> > /usr/share/applications/org.kde.amarok.desktop
> >
> > $ sudo updatedb
> > $ locate org.kde.amarok.desktop
> > /usr/share/applications/org.kde.amarok.desktop
> >
> > Now the call succeeds. It returns GDesktopAppInfo structure.
> > GDesktopAppInfo *app_info =
> g_desktop_app_info_new("org.kde.amarok.desktop")
> >
> > Something is wrong, because the manual says that the desktop file can
> stay
> > in a sub directory:
> >
> > 
> > g_desktop_app_info_new ()
> > GDesktopAppInfo * g_desktop_app_info_new (const char *desktop_id);
> >
> > Creates a new GDesktopAppInfo based on a desktop file id.
> >
> > A desktop file id is the basename of the desktop file, including the
> > .desktop extension. GIO is looking for a desktop file with this name in
> the
> > applications subdirectories of the XDG data directories (i.e. the
> > directories specified in the XDG_DATA_HOME and XDG_DATA_DIRS environment
> > variables). GIO also supports the prefix-to-subdirectory mapping that is
> > described in the Menu Spec (i.e. a desktop id of kde-foo.desktop will
> > match/usr/share/applications/kde/foo.desktop).
> > 
> >
> > Just for info:
> > My application gets the "org.kde.amarok.desktop" name from Amarok via the
> > MPRIS2 DBus-interface.  Please see "DesktopEntry" of
> >
> https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry
> >
> > Please educate me.
> >
> > Kindly
> >Osmo Moma Antero
> >Portugal
> >
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>


-- 
Sent from my PC, laptop or phone with Ubuntu-Linux.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Finding .desktop file and application info

2019-03-03 Thread tito-wolit via gtk-app-devel-list

On 3/3/19 6:36 PM, Osmo Antero via gtk-app-devel-list wrote:

Hello,
I have an application that uses g_desktop_app_info_new() function to
find GDesktopAppInfo.

I just wonder why the g_desktop_app_info_new() FAILS to find the
GDesktopAppInfo if the .desktop file is in a sub directory
under usr/share/applications/.

So this fails:
GDesktopAppInfo *app_info = g_desktop_app_info_new("org.kde.amarok.desktop")

hi,
try:

GDesktopAppInfo *app_info =
g_desktop_app_info_new("kde4-org.kde.amarok.desktop")

ciao,
Tito

If the "org.kde.amarok.desktop" file is located in:
/usr/share/applications/kde4/org.kde.amarok.desktop
This is the default location of Amarok player.
---
Then I move the file "org.kde.amarok.desktop" to /usr/share/applications/.

$ sudo mv /usr/share/applications/kde4/org.kde.amarok.desktop
/usr/share/applications/org.kde.amarok.desktop

$ sudo updatedb
$ locate org.kde.amarok.desktop
/usr/share/applications/org.kde.amarok.desktop

Now the call succeeds. It returns GDesktopAppInfo structure.
GDesktopAppInfo *app_info = g_desktop_app_info_new("org.kde.amarok.desktop")

Something is wrong, because the manual says that the desktop file can stay
in a sub directory:

g_desktop_app_info_new ()
GDesktopAppInfo * g_desktop_app_info_new (const char *desktop_id);

Creates a new GDesktopAppInfo based on a desktop file id.

A desktop file id is the basename of the desktop file, including the
.desktop extension. GIO is looking for a desktop file with this name in the
applications subdirectories of the XDG data directories (i.e. the
directories specified in the XDG_DATA_HOME and XDG_DATA_DIRS environment
variables). GIO also supports the prefix-to-subdirectory mapping that is
described in the Menu Spec (i.e. a desktop id of kde-foo.desktop will
match/usr/share/applications/kde/foo.desktop).

Just for info:
My application gets the "org.kde.amarok.desktop" name from Amarok via the
MPRIS2 DBus-interface. Please see "DesktopEntry" of
https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry

Please educate me.

Kindly
Osmo Moma Antero
Portugal

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Finding .desktop file and application info

2019-03-03 Thread Osmo Antero via gtk-app-devel-list

Hello,
I have an application that uses g_desktop_app_info_new() function to
find GDesktopAppInfo.

I just wonder why the g_desktop_app_info_new() FAILS to find the
GDesktopAppInfo if the .desktop file is in a sub directory
under usr/share/applications/.

So this fails:
GDesktopAppInfo *app_info = g_desktop_app_info_new("org.kde.amarok.desktop")
If the "org.kde.amarok.desktop" file is located in:
/usr/share/applications/kde4/org.kde.amarok.desktop
This is the default location of Amarok player.
---
Then I move the file "org.kde.amarok.desktop" to /usr/share/applications/.

$ sudo mv /usr/share/applications/kde4/org.kde.amarok.desktop
/usr/share/applications/org.kde.amarok.desktop

$ sudo updatedb
$ locate org.kde.amarok.desktop
/usr/share/applications/org.kde.amarok.desktop

Now the call succeeds. It returns GDesktopAppInfo structure.
GDesktopAppInfo *app_info = g_desktop_app_info_new("org.kde.amarok.desktop")

Something is wrong, because the manual says that the desktop file can stay
in a sub directory:

g_desktop_app_info_new ()
GDesktopAppInfo * g_desktop_app_info_new (const char *desktop_id);

Creates a new GDesktopAppInfo based on a desktop file id.

Please educate me.

Kindly
Osmo Moma Antero
Portugal

--
Sent from my PC, laptop or phone with Ubuntu-Linux.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gtk::Widget::is_mapped ()

2019-03-03 Thread Paul Davis

On Sun, Mar 3, 2019 at 9:21 AM Emmanuele Bassi  wrote:

> No, it's not. The issue is not GTK: it's the windowing system.
>
> With the advent of compositing, all windows are "visible" all the time,
> from a toolkit perspective. The compositor is responsible for building
> what's presented to the user. For example: are windows fully visible when
> doing an "exposé"-like view? Are they not? If the compositor is ultimately
> responsible of creating the final result of what's on the screen, it could
> put each window on separate planets as far as the toolkit is concerned
> (assuming latency and coordinate space size aren't a problem).
>

seems to me like an extremely uninteresting question. "expose" means "while
you, the app, doesn't know why, it's time for you to redraw (some|all) of
the contents of this window right now". visibility or otherwise doesn't
seem relevant to that.

> On Wayland is even "worse", because each window surface is completely
> separate from every other window surface by design; each window has its own
> coordinate system, that has an origin in the top-left corner of the window.
> A window *cannot* be obscured by another window, as far as the toolkit is
> concerned.
>
> If you're targeting an X11 system from the late '90s/early '00s, then
> visibility notifications *may* be emitted (though they are never
> guaranteed). On anything more modern than that, or on
> Wayland/Windows/macOS, visibility notification events are either
> non-sensical, not emitted, or not possible by design.
>

macOS as of Sierra still causes GTK(2) to generate sensible visibility
notification events. AFAIK, we still get them on current Windows systems
too.

It seems to me somewhat insane that Wayland has broken this concept (I take
you at your word that it has). Part of the job of a window manager is not
just user-facing, but also app-facing, and that includes telling an
application about the state of its window(s). It doesn't seem even remotely
unreasonable to expect that this would include visibility changes.  It's a
bit like saying "some system component could make the window any size it
chooses too at all, so it has the app has no way to know how large its
windows are."

Oh well.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk::Widget::is_mapped ()

2019-03-03 Thread Emmanuele Bassi via gtk-devel-list

No, it's not. The issue is not GTK: it's the windowing system.

With the advent of compositing, all windows are "visible" all the time,
from a toolkit perspective. The compositor is responsible for building
what's presented to the user. For example: are windows fully visible when
doing an "exposé"-like view? Are they not? If the compositor is ultimately
responsible of creating the final result of what's on the screen, it could
put each window on separate planets as far as the toolkit is concerned
(assuming latency and coordinate space size aren't a problem).

On Wayland is even "worse", because each window surface is completely
separate from every other window surface by design; each window has its own
coordinate system, that has an origin in the top-left corner of the window.
A window *cannot* be obscured by another window, as far as the toolkit is
concerned.

If you're targeting an X11 system from the late '90s/early '00s, then
visibility notifications *may* be emitted (though they are never
guaranteed). On anything more modern than that, or on
Wayland/Windows/macOS, visibility notification events are either
non-sensical, not emitted, or not possible by design.

This is why I said: "there is no way to know".

Ciao,
 Emmanuele.

On Sun, 3 Mar 2019 at 16:10, Paul Davis  wrote:

>
>
>
> On Sun, Mar 3, 2019 at 6:26 AM Emmanuele Bassi via gtk-devel-list <
> gtk-devel-list@gnome.org> wrote:
>
>> On Sun, 3 Mar 2019 at 12:58, John Emmas  wrote:
>>
>>>
>> For example... let's say the widget is a top-level window.  If it's
>>> currently displayed on screen but there's some other window hiding it
>>> (maybe from a totally different app) would 'is_visible()' return true or
>>> false?
>>>
>>
>> That's entirely different, and you should have said so at the very
>> beginning of the thread. Yes, both "visible" and "mapped" would be set to
>> true because you called show() on the window, and a window has no parents,
>> so once it's visible and realized, it'll be mapped as well; there is no way
>> to know, from a toolkit perspective, if a top level is being partially, or
>> totally, covered by some other window, either in the same process or from a
>> different process. That information is only available to the window manager.
>>
>
> John should really know that there's code to do this (to the best extent
> possible) within the Ardour source code at
> libs/gtkmm2ext/visibility_tracker.cc :)))
>
> It works (to whatever extent it does work) by handling GtkEventVisibility
> notifications. Hopefully this is still possible in GTK3 ?
>
>

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk::Widget::is_mapped ()

2019-03-03 Thread Paul Davis

On Sun, Mar 3, 2019 at 6:26 AM Emmanuele Bassi via gtk-devel-list <
gtk-devel-list@gnome.org> wrote:

> On Sun, 3 Mar 2019 at 12:58, John Emmas  wrote:
>
>>
> For example... let's say the widget is a top-level window.  If it's
>> currently displayed on screen but there's some other window hiding it
>> (maybe from a totally different app) would 'is_visible()' return true or
>> false?
>>
>
> That's entirely different, and you should have said so at the very
> beginning of the thread. Yes, both "visible" and "mapped" would be set to
> true because you called show() on the window, and a window has no parents,
> so once it's visible and realized, it'll be mapped as well; there is no way
> to know, from a toolkit perspective, if a top level is being partially, or
> totally, covered by some other window, either in the same process or from a
> different process. That information is only available to the window manager.
>

John should really know that there's code to do this (to the best extent
possible) within the Ardour source code at
libs/gtkmm2ext/visibility_tracker.cc :)))

It works (to whatever extent it does work) by handling GtkEventVisibility
notifications. Hopefully this is still possible in GTK3 ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk::Widget::is_mapped ()

2019-03-03 Thread Emmanuele Bassi via gtk-devel-list

On Sun, 3 Mar 2019 at 12:58, John Emmas  wrote:

> On 03/03/2019 11:22, Emmanuele Bassi wrote:
>
> On Sun, 3 Mar 2019 at 11:09, John Emmas  wrote:
>
>> Sorry to ask a dumb question...
>>
>> What does it mean if a widget is "mapped" ?
>>
>
> It means that:
>
>  - the widget is visible
>  - the widget is realized
>  - all its ancestors up to the top level window are mapped
>
> Thanks Emmanuele - can I just check 'is_visible()'?  Does it mean
> 'literally visible' or 'capable of being visible'?
>

If it were enough, why would we have two flags? :-)

The "visible" property means "you, or something else, called
gtk_widget_show()" on the widget. A widget can be visible and not have any
parent, for instance.

If you want to know that a widget is going to be drawn, and respond to
events, then you have to check the "mapped" state.

For example... let's say the widget is a top-level window.  If it's
> currently displayed on screen but there's some other window hiding it
> (maybe from a totally different app) would 'is_visible()' return true or
> false?
>

That's entirely different, and you should have said so at the very
beginning of the thread. Yes, both "visible" and "mapped" would be set to
true because you called show() on the window, and a window has no parents,
so once it's visible and realized, it'll be mapped as well; there is no way
to know, from a toolkit perspective, if a top level is being partially, or
totally, covered by some other window, either in the same process or from a
different process. That information is only available to the window manager.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk::Widget::is_mapped ()

2019-03-03 Thread John Emmas


On 03/03/2019 11:22, Emmanuele Bassi wrote:
On Sun, 3 Mar 2019 at 11:09, John Emmas > wrote:


Sorry to ask a dumb question...

What does it mean if a widget is "mapped" ?


It means that:

 - the widget is visible
 - the widget is realized
 - all its ancestors up to the top level window are mapped

Thanks Emmanuele - can I just check 'is_visible()'?  Does it mean 
'literally visible' or 'capable of being visible'?


For example... let's say the widget is a top-level window.  If it's 
currently displayed on screen but there's some other window hiding it 
(maybe from a totally different app) would 'is_visible()' return true or 
false?


John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Gtk::Widget::is_mapped ()

2019-03-03 Thread John Emmas


Sorry to ask a dumb question...

What does it mean if a widget is "mapped" ?

Thanks, John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Finding .desktop file and application info

Re: Finding .desktop file and application info

Re: Finding .desktop file and application info

Finding .desktop file and application info

Re: Gtk::Widget::is_mapped ()

Re: Gtk::Widget::is_mapped ()

Re: Gtk::Widget::is_mapped ()

Re: Gtk::Widget::is_mapped ()

Re: Gtk::Widget::is_mapped ()

Gtk::Widget::is_mapped ()

10 matches

Site Navigation

Mail list logo

Footer information