You are not logged in.

#1 2010-11-14 06:35:10

ShadowKyogre
Member
From: Hell! XP No... I'm not telling
Registered: 2008-12-19
Posts: 476
Website

Compiz-boxmenu, fork of compiz-deskmenu

[EDIT]: Title used to be "Compiz-deskmenu patch adding pipeitems, extensive icon support, etc."
It came to me that compiz-deskmenu should be able to fill in the gaps that Compiz has as a standalone environment, since it had a viewport list and a window list. As such, I decided to start patching the program to suit this goal. I've added several features and fixed a few bugs that I found in the program. The updates can be found in the below link to it (and a previous revision with my previous patches can be found on the AUR).

Source tarball:
Current version (AUR Package)
Current version with experimental filebrowser
I'll remove the link when the updates hit the AUR package for this.
Project page: https://sourceforge.net/projects/compizboxmenu/

[EDIT]: Please see the Cumulative Changelog news entry on the project page. This post is getting too crowded.

Screenshot of how pipeitems behave in case my explanation isn't clear:
tNjVrcA

Screenshot of extensive icon support:
tNjQyMw

Screenshot of viewport icon choice in action:
tNjZwcg

Screenshot of recent documents list (before a quick fix):
tNjgzYw

Any feature requests, bug reports, etc. are welcome smile

Last edited by ShadowKyogre (2011-02-17 20:22:29)


For every problem, there is a solution that is:
Clean
Simple and most of all...wrong!
Github page

Offline

#2 2010-11-14 17:39:11

pogeymanz
Member
Registered: 2008-03-11
Posts: 1,020

Re: Compiz-boxmenu, fork of compiz-deskmenu

Wow, this is great! Compiz-deskmenu was pretty lame before, but this is now better than MyGtkMenu.

Thanks.

Now just to get my nvidia driver issue figured out so I can use Compiz again...

Offline

#3 2010-11-14 19:57:15

ShadowKyogre
Member
From: Hell! XP No... I'm not telling
Registered: 2008-12-19
Posts: 476
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:

Wow, this is great! Compiz-deskmenu was pretty lame before, but this is now better than MyGtkMenu.

Thanks.

Now just to get my nvidia driver issue figured out so I can use Compiz again...

Welcome smile And that sucks sad I was planning to put an Nvidia graphics card on my computer until I heard about that.


For every problem, there is a solution that is:
Clean
Simple and most of all...wrong!
Github page

Offline

#4 2010-11-14 20:03:14

pogeymanz
Member
Registered: 2008-03-11
Posts: 1,020

Re: Compiz-boxmenu, fork of compiz-deskmenu

I never had a problem in years of using Nvidia. It's just this latest driver that's messed me up.

I can always try to use nouveau and Compiz...

Offline

#5 2010-11-14 20:38:32

sugardeath
Member
Registered: 2010-03-02
Posts: 82

Re: Compiz-boxmenu, fork of compiz-deskmenu

Is it possible to use more than one menu with compiz-deskmenu?  I know there's the -m flag, but it still displays the normal menu no matter what file I specify.  This is one of the major features I am missing from Openbox.

I'm on the wrong computer to update to your version, but as soon as I can, I will check it out.

Offline

#6 2010-11-14 20:58:18

ShadowKyogre
Member
From: Hell! XP No... I'm not telling
Registered: 2008-12-19
Posts: 476
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:

I never had a problem in years of using Nvidia. It's just this latest driver that's messed me up.

I can always try to use nouveau and Compiz...

Ah sad Hope that works for you.

sugardeath wrote:

Is it possible to use more than one menu with compiz-deskmenu?  I know there's the -m flag, but it still displays the normal menu no matter what file I specify.  This is one of the major features I am missing from Openbox.

I'm on the wrong computer to update to your version, but as soon as I can, I will check it out.

Yes, but apparently the dbus-client compiz-deskmenu doesn't pass this argument down to the actual binary, compiz-deskmenu-menu. In order to use another file, one would have to use compiz-deskmenu-menu -m /path/to/your/menu.xml. I still need to figure out why it's dependent on dbus, since I can't seem to spot what's passing down which variables via dbus (so the two fixes for that problem would either be having the dbus client pass down the argument or remove the program's dbus dependency).

To all: Viewport numbers just got added to the window list, will be updating to main post shortly.


For every problem, there is a solution that is:
Clean
Simple and most of all...wrong!
Github page

Offline

#7 2010-11-14 22:52:22

pogeymanz
Member
Registered: 2008-03-11
Posts: 1,020

Re: Compiz-boxmenu, fork of compiz-deskmenu

Here's a request, but it may not be easy/feasible:

Add a daemon to compiz-deskmenu so that it keeps the menu loaded in memory and issuing the command will display it.

One thing that always bothered me about compiz-deskmenu and myGtkMenu was that they always took a noticeable amount of time to load after I right-clicked my desktop. In Openbox/XFCE/PekWM/etc, it's instant, presumably because the menu is cached away in memory somehow.

So we could then add something like
compiz-deskmenu-daemon &

to our compiz startup file and every time we issue 'compiz-deskmenu' it can load nearly instantly!

Of course then you'd want any edits to update the daemon while it's running, so the changes are immediate.

Like I said, I don't know if that's something you'd be willing to look at, but it would make Compiz Standalone feel more complete and seamless.

Last edited by pogeymanz (2010-11-14 22:56:52)

Offline

#8 2010-11-15 00:13:27

sugardeath
Member
Registered: 2010-03-02
Posts: 82

Re: Compiz-boxmenu, fork of compiz-deskmenu

ShadowKyogre wrote:

In order to use another file, one would have to use compiz-deskmenu-menu -m /path/to/your/menu.xml.

I tried that, but nothing ever displayed, valid file or not.  Running the normal one with -m yields the normal menu.  Running -menu with -m yields... nothing.  At all.  The program just seems to hang with no output when run from the console.

Offline

#9 2010-11-15 01:13:24

ShadowKyogre
Member
From: Hell! XP No... I'm not telling
Registered: 2008-12-19
Posts: 476
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:

Here's a request, but it may not be easy/feasible:

Add a daemon to compiz-deskmenu so that it keeps the menu loaded in memory and issuing the command will display it.

One thing that always bothered me about compiz-deskmenu and myGtkMenu was that they always took a noticeable amount of time to load after I right-clicked my desktop. In Openbox/XFCE/PekWM/etc, it's instant, presumably because the menu is cached away in memory somehow.

So we could then add something like
compiz-deskmenu-daemon &

to our compiz startup file and every time we issue 'compiz-deskmenu' it can load nearly instantly!

Of course then you'd want any edits to update the daemon while it's running, so the changes are immediate.

Like I said, I don't know if that's something you'd be willing to look at, but it would make Compiz Standalone feel more complete and seamless.

It sounds like an interesting idea, though I'm not sure how to approach it (along with the multiple files thing without making it too tedious on the user). What I'm currently thinking for the daemon is something like this:
1. Create an array that holds the files given to the daemon (if none are given, then the daemon loads the default menu. compiz-deskmenu should feed the file to the daemon if given as an argument)
2. Check the cached file array until it matches the given path of the file
3. Load the cached contents of that file
4. If not in the cache, grab the file and parse it normally
5. If the file is cached, just (re)parse its contents (there also probably needs to be something to check if the contents are different before refreshing it)
6. Possibly a configuration file that preloads certain files upon startup

sugardeath wrote:
ShadowKyogre wrote:

In order to use another file, one would have to use compiz-deskmenu-menu -m /path/to/your/menu.xml.

I tried that, but nothing ever displayed, valid file or not.  Running the normal one with -m yields the normal menu.  Running -menu with -m yields... nothing.  At all.  The program just seems to hang with no output when run from the console.

*facepalms at myself* I almost forgot that the program still relies on compiz-deskmenu in order for it to appear. I still need to make this dbus agnostic.


For every problem, there is a solution that is:
Clean
Simple and most of all...wrong!
Github page

Offline

#10 2010-11-15 05:39:24

sugardeath
Member
Registered: 2010-03-02
Posts: 82

Re: Compiz-boxmenu, fork of compiz-deskmenu

ShadowKyogre wrote:

*facepalms at myself* I almost forgot that the program still relies on compiz-deskmenu in order for it to appear. I still need to make this dbus agnostic.

Haha, don't worry about it!  Though, I do eagerly await such a fix. smile

Offline

#11 2010-11-16 03:40:13

ShadowKyogre
Member
From: Hell! XP No... I'm not telling
Registered: 2008-12-19
Posts: 476
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

sugardeath wrote:
ShadowKyogre wrote:

*facepalms at myself* I almost forgot that the program still relies on compiz-deskmenu in order for it to appear. I still need to make this dbus agnostic.

Haha, don't worry about it!  Though, I do eagerly await such a fix. smile

I'm currently working on it now on a copy smile. Only problem now is to get the DeskmenuClass to initialize (which is what dbus does). In the meantime, I've worked in the viewport icon choice into the program.

Current source tarball: http://dl.dropbox.com/u/12096853/compiz … src.tar.gz

Screenshot of it in action:
tNjZwcg

[EDIT]: Just to be sure, does anyone want an Apwal/oblogout-esque mode for this (which would be a floating button toolbar that has dropdown menus), with the names as tooltips and the items being image-only buttons? Just a strange idea regarding this project that came to my head.

[EDIT]: Just got rid of dbus from the program now. I've updated the source tarballs.

Last edited by ShadowKyogre (2010-11-16 22:31:30)


For every problem, there is a solution that is:
Clean
Simple and most of all...wrong!
Github page

Offline

#12 2010-11-18 23:58:37

ShadowKyogre
Member
From: Hell! XP No... I'm not telling
Registered: 2008-12-19
Posts: 476
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

Sorry for the double post, but this is a major update. There's a new item type I added to compiz-deskmenu which takes advantage of GTK+'s native recent documents support. You can configure it to have icons, display only a certain number of items, sort the items by usage frequency, and/or display only items from X days ago. This is SIGNIFICANTLY faster than using a pipeitem to grab the items and perhaps more flexible. Next up will be menu icon size configuration (if the recent documents menu doesn't decide to do something weird when changing the icon size), since I got the basics behind this done from adding this feature.

Screenshot:
tNjgzYw

pkgbuild source tarball:
http://dl.dropbox.com/u/12096853/compiz … src.tar.gz

Notes:
If you notice the slight change in the PKGBUILD, it's because I'm preparing to submit it to the git repository for it.

Also, if you see this while building (copypasta'd directly from the edited README):

cc `pkg-config --cflags gdk-2.0 gtk+-2.0 libwnck-1.0` -O2 -Wall -Wextra -Wno-unused-parameter `pkg-config --libs gdk-2.0 gtk+-2.0 libwnck-1.0` -o compiz-deskmenu deskmenu-menu.c deskmenu-wnck.c
deskmenu-menu.c: In function 'deskmenu_construct_item':
deskmenu-menu.c:246:5: warning: passing argument 1 of 'gtk_recent_chooser_set_show_icons' from incompatible pointer type
/usr/include/gtk-2.0/gtk/gtkrecentchooser.h:146:19: note: expected 'struct GtkRecentChooser *' but argument is of type 'struct GtkWidget *'
deskmenu-menu.c:260:5: warning: passing argument 1 of 'gtk_recent_chooser_set_show_icons' from incompatible pointer type
/usr/include/gtk-2.0/gtk/gtkrecentchooser.h:146:19: note: expected 'struct GtkRecentChooser *' but argument is of type 'struct GtkWidget *'
deskmenu-menu.c:269:17: warning: passing argument 1 of 'gtk_recent_chooser_add_filter' from incompatible pointer type
/usr/include/gtk-2.0/gtk/gtkrecentchooser.h:179:9: note: expected 'struct GtkRecentChooser *' but argument is of type 'struct GtkWidget *'
deskmenu-menu.c:274:7: warning: passing argument 1 of 'gtk_recent_chooser_set_sort_type' from incompatible pointer type
/usr/include/gtk-2.0/gtk/gtkrecentchooser.h:149:19: note: expected 'struct GtkRecentChooser *' but argument is of type 'struct GtkWidget *'
deskmenu-menu.c:278:7: warning: passing argument 1 of 'gtk_recent_chooser_set_sort_type' from incompatible pointer type
/usr/include/gtk-2.0/gtk/gtkrecentchooser.h:149:19: note: expected 'struct GtkRecentChooser *' but argument is of type 'struct GtkWidget *'
deskmenu-menu.c:287:5: warning: passing argument 1 of 'gtk_recent_chooser_set_limit' from incompatible pointer type
/usr/include/gtk-2.0/gtk/gtkrecentchooser.h:132:19: note: expected 'struct GtkRecentChooser *' but argument is of type 'struct GtkWidget *'
deskmenu-menu.c:291:5: warning: passing argument 1 of 'gtk_recent_chooser_set_limit' from incompatible pointer type
/usr/include/gtk-2.0/gtk/gtkrecentchooser.h:132:19: note: expected 'struct GtkRecentChooser *' but argument is of type 'struct GtkWidget *'

That is perfectly normal since the gtkrecentchoosermenu widget implements the same stuff from gtkrecentchooser.

[EDIT]: It's acting a bit weird for not allowing you to open items like this, I'll go back and fix that.
[EDIT]: The previous behavior I mentioned is now fixed

Last edited by ShadowKyogre (2010-11-21 05:06:54)


For every problem, there is a solution that is:
Clean
Simple and most of all...wrong!
Github page

Offline

#13 2010-11-23 20:08:49

imak
Member
Registered: 2010-11-23
Posts: 1

Re: Compiz-boxmenu, fork of compiz-deskmenu

Silly feature request.

Would it be possible to implement a custom animated menu entry highlight feature?

As shown in this clip? http://www.youtube.com/watch?v=IKXXVZs9Hgg

Would be a great addition to standalone desktop effects.

Offline

#14 2010-11-24 00:39:13

ShadowKyogre
Member
From: Hell! XP No... I'm not telling
Registered: 2008-12-19
Posts: 476
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

imak wrote:

Silly feature request.

Would it be possible to implement a custom animated menu entry highlight feature?

As shown in this clip? http://www.youtube.com/watch?v=IKXXVZs9Hgg

Would be a great addition to standalone desktop effects.

If by that you mean the little shine that happens when the menu entry is highlighted in the video, I think this would have to be done through customizing you GTK+ theme or including a little theme snippet in your gtkrc configs in order for this to happen (which might involve setting a custom theme engine setting for that specific application).

If you meant the menu shattering, all you have to do is add an appropriate effect for when the menu pops up via CCSM.

==
To everyone:
I'm about to change the separator decoration mode from setting the menu entry to prelight to instead stuffing a button inside a separator menu entry.
Which of the two is better and why (just to note: stuffing buttons in the menu entries makes the menu load a bit longer if you have these)?
tNmFkaw
Left: prelighted entry
Right: stuffed buttons into menu entry, rough draft
I'm also currently brainstorming the code for a daemon mode to reduce load times. Don't know if I'll have to reimplement dbus or not.


For every problem, there is a solution that is:
Clean
Simple and most of all...wrong!
Github page

Offline

#15 2010-11-24 00:54:23

pogeymanz
Member
Registered: 2008-03-11
Posts: 1,020

Re: Compiz-boxmenu, fork of compiz-deskmenu

ShadowKyogre wrote:
imak wrote:

Silly feature request.

Would it be possible to implement a custom animated menu entry highlight feature?

As shown in this clip? http://www.youtube.com/watch?v=IKXXVZs9Hgg

Would be a great addition to standalone desktop effects.

If by that you mean the little shine that happens when the menu entry is highlighted in the video, I think this would have to be done through customizing you GTK+ theme or including a little theme snippet in your gtkrc configs in order for this to happen (which might involve setting a custom theme engine setting for that specific application).

If you meant the menu shattering, all you have to do is add an appropriate effect for when the menu pops up via CCSM.

==
To everyone:
I'm about to change the separator decoration mode from setting the menu entry to prelight to instead stuffing a button inside a separator menu entry.
Which of the two is better and why (just to note: stuffing buttons in the menu entries makes the menu load a bit longer if you have these)?
I'm also currently brainstorming the code for a daemon mode to reduce load times. Don't know if I'll have to reimplement dbus or not.

Either of those seem fine enough. Just go with simpler.

Also, you're officially my hero if/when you implement the daemon mode.

Offline

#16 2010-11-24 02:18:22

ShadowKyogre
Member
From: Hell! XP No... I'm not telling
Registered: 2008-12-19
Posts: 476
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:

Either of those seem fine enough. Just go with simpler.

Also, you're officially my hero if/when you implement the daemon mode.

I'll go with the prelight method then for the decorators, and I'll try to implement daemon mode as soon as I can (right now, on my machine, there's a one second delay between launching the command and opening the menu, which probably means I need to cut down the load time a LOT if it's going to be usable with a bunch of pipeitems)
Version with prelight: http://dl.dropbox.com/u/12096853/compiz … src.tar.gz
Version with buttons embedded: http://dl.dropbox.com/u/12096853/compiz … src.tar.gz
==
To everyone:
I recently uploaded some pipeitems to use for this version of compiz-deskmenu. You can get them from this AUR package: http://aur.archlinux.org/packages.php?ID=43863. Be sure to read the README included in the package.


For every problem, there is a solution that is:
Clean
Simple and most of all...wrong!
Github page

Offline

#17 2010-11-26 03:35:56

rufflove
Member
From: Holmfirth, UK
Registered: 2010-11-22
Posts: 96

Re: Compiz-boxmenu, fork of compiz-deskmenu

I prefer the prelighted (prelit/highlighted?) separator on the left because it looks like an actual header, whereas the righthand one just looks like it isn't sure whether it is a header or a button tongue

I would like to test your patches out, but unfortunately it odesn't work with Compiz-09, it seems. I'll stick with mygtkmenu for now, which has the big advantage of being WM agnostic, meaning I can do a 'metacity --replace' on my portable Arch install, if the host machine disagrees with Compiz, without losing my apps menu... Saying that, there is always the PCManFM apps menu instead...

I remember seeing some scripts for menumaker recently that added generation of a dynamic submenu consisting of commands to open each mounted volume in a file manager. Kind of funky, but also superfluous; like the viewport switcher already in compiz-deskmenu. I think having easier access to recent documents is an attractive feature, though.

If it were me, I'd look to the Linux Mint menu for inspiration wink Anyway, good luck with the changes!


"Its too big and too slow"

Offline

#18 2010-11-26 14:03:56

pogeymanz
Member
Registered: 2008-03-11
Posts: 1,020

Re: Compiz-boxmenu, fork of compiz-deskmenu

So, I really like this compiz-deskmenu, however. For whatever reason, it doesn't always work when I right-click my desktop. Sometimes 'compiz-deskmenu' appears in top but never actually opens a menu for me. I can usually only successfully launch it once or twice per session. MyGTKMenu has no such problem, so I don't think it's my configuration.

Offline

#19 2010-11-26 17:49:36

ShadowKyogre
Member
From: Hell! XP No... I'm not telling
Registered: 2008-12-19
Posts: 476
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

rufflove wrote:

I prefer the prelighted (prelit/highlighted?) separator on the left because it looks like an actual header, whereas the righthand one just looks like it isn't sure whether it is a header or a button tongue

I would like to test your patches out, but unfortunately it odesn't work with Compiz-09, it seems. I'll stick with mygtkmenu for now, which has the big advantage of being WM agnostic, meaning I can do a 'metacity --replace' on my portable Arch install, if the host machine disagrees with Compiz, without losing my apps menu... Saying that, there is always the PCManFM apps menu instead...

I remember seeing some scripts for menumaker recently that added generation of a dynamic submenu consisting of commands to open each mounted volume in a file manager. Kind of funky, but also superfluous; like the viewport switcher already in compiz-deskmenu. I think having easier access to recent documents is an attractive feature, though.

If it were me, I'd look to the Linux Mint menu for inspiration wink Anyway, good luck with the changes!

Hm, can I have a link to this? I was contemplating how to make a pipeitem for this function, but maybe I can implement something like this.

And thank you smile

pogeymanz wrote:

So, I really like this compiz-deskmenu, however. For whatever reason, it doesn't always work when I right-click my desktop. Sometimes 'compiz-deskmenu' appears in top but never actually opens a menu for me. I can usually only successfully launch it once or twice per session. MyGTKMenu has no such problem, so I don't think it's my configuration.

Weird. I usually got the same problem if I launched it using a screen edge binding (I am using Compiz++, but I don't know if that makes as much a difference). What I've done for now is to make a launcher that launches the menu until some of the kinks are worked out (like getting right-click to actually work in Compiz++ since there's some REALLY weird behavior if you try to launch a commands plugin command not using the command, eg: viewport switcher). It should then launch every time you click on the launcher.

==
To everyone:
The functionality for the daemon mode is almost done except for the cache contents not writing to the cache matrix. Currently trying to hammer the kink out of this.


For every problem, there is a solution that is:
Clean
Simple and most of all...wrong!
Github page

Offline

#20 2010-11-26 19:01:33

pogeymanz
Member
Registered: 2008-03-11
Posts: 1,020

Re: Compiz-boxmenu, fork of compiz-deskmenu

ShadowKyogre wrote:
pogeymanz wrote:

So, I really like this compiz-deskmenu, however. For whatever reason, it doesn't always work when I right-click my desktop. Sometimes 'compiz-deskmenu' appears in top but never actually opens a menu for me. I can usually only successfully launch it once or twice per session. MyGTKMenu has no such problem, so I don't think it's my configuration.

Weird. I usually got the same problem if I launched it using a screen edge binding (I am using Compiz++, but I don't know if that makes as much a difference). What I've done for now is to make a launcher that launches the menu until some of the kinks are worked out (like getting right-click to actually work in Compiz++ since there's some REALLY weird behavior if you try to launch a commands plugin command not using the command, eg: viewport switcher). It should then launch every time you click on the launcher.

I noticed that when I try it in Compiz++, it just crashes Compiz. I am using the .8 version in the repos and it's doing the odd behavior. It even happens if I just use the key-binding I set for it in the Commands plugin.

Yet, it'll launch every time from a terminal or launcher or dmenu...

Offline

#21 2010-11-26 19:52:00

rufflove
Member
From: Holmfirth, UK
Registered: 2010-11-22
Posts: 96

Re: Compiz-boxmenu, fork of compiz-deskmenu

Hm, can I have a link to this? I was contemplating how to make a pipeitem for this function, but maybe I can implement something like this.

Sorry, I can't find the page in my history, but if I remember rightly the snippets I saw queried HAL rather than udisks...


"Its too big and too slow"

Offline

#22 2010-11-27 05:00:21

ShadowKyogre
Member
From: Hell! XP No... I'm not telling
Registered: 2008-12-19
Posts: 476
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:

I noticed that when I try it in Compiz++, it just crashes Compiz. I am using the .8 version in the repos and it's doing the odd behavior. It even happens if I just use the key-binding I set for it in the Commands plugin.

Yet, it'll launch every time from a terminal or launcher or dmenu...

It might be a problem with the commands plugin then *shrugs* but it hasn't happened with my other applications yet. I'll try to see what's causing this.

rufflove wrote:

Sorry, I can't find the page in my history, but if I remember rightly the snippets I saw queried HAL rather than udisks...

Ah sad I'll have to read up more on udisks then.
==
To everyone:
Finished implementing daemon mode by turning the main binary into a daemon that uses dbus. Tarball: http://dl.dropbox.com/u/12096853/compiz … src.tar.gz
The client binary is compiz-deskmenu, which should start compiz-deskmenu-daemon if it isn't started.
This fix also stitches the split text back together so error reporting can resume its normal behavior in compiz-deskmenu. On my machine, it doesn't seem to give a noticable performance boost (give or take a few milliseconds). Does anyone see noticable performance results with this new version?


For every problem, there is a solution that is:
Clean
Simple and most of all...wrong!
Github page

Offline

#23 2010-11-27 14:15:56

pogeymanz
Member
Registered: 2008-03-11
Posts: 1,020

Re: Compiz-boxmenu, fork of compiz-deskmenu

ShadowKyogre wrote:

To everyone:
Finished implementing daemon mode by turning the main binary into a daemon that uses dbus. Tarball: http://dl.dropbox.com/u/12096853/compiz … src.tar.gz
The client binary is compiz-deskmenu, which should start compiz-deskmenu-daemon if it isn't started.
This fix also stitches the split text back together so error reporting can resume its normal behavior in compiz-deskmenu. On my machine, it doesn't seem to give a noticable performance boost (give or take a few milliseconds). Does anyone see noticable performance results with this new version?

I can't tell if it's significantly faster, BUT it does seem to launch consistently now for me... So still good for me! smile

I wonder now if any speed issue is from Compiz itself. It has to go through the Viewport Plugin to the Command Plugin, THEN issue the command. Perhaps along that path is some inefficiency?

EDIT: Thinking along the same lines... Have you considered creating a Compiz plugin for just this menu? I don't have a clue how that would work, but I wonder if it would provide a nicer integration (and clear up a command slot).

Also, you should probably consider this project a fork, rather than a patch. A patch usually adds or fixes something small, but now you've added several features. Time to name your project!

Last edited by pogeymanz (2010-11-27 14:24:47)

Offline

#24 2010-11-27 20:59:13

ShadowKyogre
Member
From: Hell! XP No... I'm not telling
Registered: 2008-12-19
Posts: 476
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:

I can't tell if it's significantly faster, BUT it does seem to launch consistently now for me... So still good for me! smile

I wonder now if any speed issue is from Compiz itself. It has to go through the Viewport Plugin to the Command Plugin, THEN issue the command. Perhaps along that path is some inefficiency?

EDIT: Thinking along the same lines... Have you considered creating a Compiz plugin for just this menu? I don't have a clue how that would work, but I wonder if it would provide a nicer integration (and clear up a command slot).

Also, you should probably consider this project a fork, rather than a patch. A patch usually adds or fixes something small, but now you've added several features. Time to name your project!

Hooray! big_smile I think that might be the case. I haven't considered making a compiz-plugin for it, but I supposed it would borrow some code from the already existing desktopclick plugin (which isn't a plugin that has a group, but focuses specifically on clicking the root window). Loading whatever files for the deskmenu might be a bit of a hassle though.
==
To everyone: I've set up the sourceforge page for this: https://sourceforge.net/projects/compizboxmenu/ I'll try to write up a PKGBUILD for this tomorrow, since I'm a bit busy right now.

Last edited by ShadowKyogre (2010-11-27 21:00:27)


For every problem, there is a solution that is:
Clean
Simple and most of all...wrong!
Github page

Offline

#25 2010-11-28 20:05:09

pogeymanz
Member
Registered: 2008-03-11
Posts: 1,020

Re: Compiz-boxmenu, fork of compiz-deskmenu

An issue now is that the menu launches everything from / as its working directory. So Thunar and my terminal open / instead of ~/.

Offline

Board footer

Powered by FluxBB