You are not logged in.

#26 2010-11-29 23:48:25

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:

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

I think it has to do something with how it spawns a command (it uses the same function as myGTKMenu). What happens is that it'll try to open the program in the working directory that the daemon was launched from. So if it's picking /, then it's most likely that the daemon is being launched from /.

[EDIT]: Apparently dbus launches the daemon from /, which explains why this is causing this. And apparently implementing dbus breaks the menus for the viewport list and the windowlist (which most likely has to do with the menu refresh method) if they are viewed a second time.

[EDIT]: the mentioned behavior is now fixed

Last edited by ShadowKyogre (2010-12-04 00:26:57)


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

Offline

#27 2010-12-06 21:47:06

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

Sorry for another double-post, but it's another major update. I finally got around to making the PKGBUILD now that my classes are over.
source tarball: http://dl.dropbox.com/u/12096853/compiz … src.tar.gz

So some of the new things in here are precacheing, being able to pin menus, and being able to call up the viewportlist, documentlist, and windowlist separately from your main menu. There are three binaries to deal with each of these types (note: the windowlist has a little glitch as a service where it does not detect windows upon the first call. Every other call will be fine.).

[EDIT]: The previous behavior I mentioned should be fixed now.

I might also get around to making a filebrowser, although that's going to be a bit tricky.

Screenshot:
tNmdkag

Last edited by ShadowKyogre (2010-12-06 23:47:01)


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

Offline

#28 2010-12-07 22:57:52

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

ShadowKyogre wrote:

Sorry for another double-post, but it's another major update. I finally got around to making the PKGBUILD now that my classes are over.
So some of the new things in here are precacheing, being able to pin menus, and being able to call up the viewportlist, documentlist, and windowlist separately from your main menu. There are three binaries to deal with each of these types (note: the windowlist has a little glitch as a service where it does not detect windows upon the first call. Every other call will be fine.).

[EDIT]: The previous behavior I mentioned should be fixed now.

I might also get around to making a filebrowser, although that's going to be a bit tricky.

This is great stuff! Thanks for this app. I has been long-needed for Compiz-Standalone.

The only problem now is that Viewport Switcher only allows us to map one command on the root window. I'd love it if I could right-click for apps menu and middle-click for window list.

Offline

#29 2010-12-07 23:51:24

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:
ShadowKyogre wrote:

Sorry for another double-post, but it's another major update. I finally got around to making the PKGBUILD now that my classes are over.
So some of the new things in here are precacheing, being able to pin menus, and being able to call up the viewportlist, documentlist, and windowlist separately from your main menu. There are three binaries to deal with each of these types (note: the windowlist has a little glitch as a service where it does not detect windows upon the first call. Every other call will be fine.).

[EDIT]: The previous behavior I mentioned should be fixed now.

I might also get around to making a filebrowser, although that's going to be a bit tricky.

This is great stuff! Thanks for this app. I has been long-needed for Compiz-Standalone.

The only problem now is that Viewport Switcher only allows us to map one command on the root window. I'd love it if I could right-click for apps menu and middle-click for window list.

You're welcome smile. As for that issue, there's another plugin that deals with desktop clicking solely. It's desktopclick (right here: http://cgit.compiz.org/~smspillaz/desktopclick/ ). I haven't tested the 0.8 branch of it, but I can tell the compiz++ version of it "works" (if you count the launching command outside of the command plugin crashing working. I have no idea if that's been fixed yet, because I've been having a bit of trouble recompiling to the latest git version of compiz++).

Last edited by ShadowKyogre (2010-12-07 23:51:47)


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

Offline

#30 2010-12-09 18:14:14

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

I'm having trouble building that plugin. When I run cmake .. in the directory, I get this error:

CMake Error at /usr/share/cmake-2.8/Modules/FindCompiz.cmake:85 (message):
  Unable to find Compiz
Call Stack (most recent call first):
  CMakeLists.txt:1 (find_package)

Do you know what that is?

Offline

#31 2010-12-09 22:15:10

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:

I'm having trouble building that plugin. When I run cmake .. in the directory, I get this error:

CMake Error at /usr/share/cmake-2.8/Modules/FindCompiz.cmake:85 (message):
  Unable to find Compiz
Call Stack (most recent call first):
  CMakeLists.txt:1 (find_package)

Do you know what that is?

It looks like you pulled the compiz++ branch. You can check out the compiz-0.8 branch with this after going into the directory that the files for the plugin are in:

git checkout compiz-0.8

[EDIT]: Just editing this post instead of making a double post, because this is about a tenative feature.
To everyone:
tNmlqMw
I've finished making a filebrowser for it that can use thumb drives and your gtk-bookmarks. But is this bloat or needed, since this can be achieved by a pipeitem (though it might take a long time if done with a pipeitem)?

Last edited by ShadowKyogre (2010-12-11 06:37:22)


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

Offline

#32 2010-12-12 03:30:22

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

Well, I don't really care for it... I never used that kind of stuff with Openbox either... If I want to browse files, I open a terminal or a file manager.

That Desktopclick plugin installed once I took your advice, but it's pretty buggy in Compiz .8.6

Offline

#33 2010-12-12 07:45:47

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:

Well, I don't really care for it... I never used that kind of stuff with Openbox either... If I want to browse files, I open a terminal or a file manager.

That Desktopclick plugin installed once I took your advice, but it's pretty buggy in Compiz .8.6

Ah, okay. I'm going to hold off on pushing the changes until I can make a configure script to toggle the features (which hopefully would mean toggling DBUS support). As for the plugin, what is it doing?

To everyone:
I think development's going to be much slower than it has been for the past few days/weeks. The next impending changes reflect more administrative changes (if, for some reason, there's a compiz standalone live CD, etc.). Here's a brief list of what will be happening:
*First and foremost, getting the windowlist and viewport list to autoupdate again without listening to signals when included in the main menu. This idea came from my experiment with the filebrowser (which had to autoupdate the subfolder entries to reduce wait time on the program), and would involve having a separate function to initialize the settings for each of these items, and passing these settings to the deskmenu_*_new functions to make widgets based on the settings gathered. Whenever the user would open up the item that contains the submenu holding the contents for these, this would autoupdate in the same manner.

*Secondly, although it might be very, very difficult, is to port the current GMarkupParser menu constructor to LibXML2's SAX or DOM parser, whichever fits the needs of the program more. Since the GMarkupParser works in a similar way to the SAX parser, it seems most plausible to port to this parser. With this, the program will get the added benefit of reading menu files DIRECTLY instead of shoving them in memory. This will also make it convenient to cache certain pipeitem outputs, although the pipeitems will have to have some tags declaring they're "documents" of the pipeitem type. This will also allow for some nesting of pipes and another feature that might come because of this change.

*Thirdly, if I can port it to the SAX parser, will be the inclusion of menu files in menu files (like the way there's <file>/path/to/debian/menu.xml</file> in Openbox for debian-based systems). Although this can be achieved with cacheing a pipeitem that goes "cat /path/to/file/menu.xml|sed 's|somecommand|somesubstitution|'|etc.", it would be more useful if it read it directly from the file, again. If this does come out, I'll include options to either import the file as a submenu or import just the items contained in that menu.

*Fourthly, although this could be considered the most plausible of the changes, is keeping the compiz-boxmenu-editor file as the version used for dbus. For one, people might have some tags floating around from one version that they want to remove when they switch to another. Another reason for this is that, well, its dbus talking is toggled upon the presence of the daemon.


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

Offline

#34 2010-12-12 23:04:58

karabaja4
Member
From: Croatia
Registered: 2008-09-14
Posts: 840

Re: Compiz-boxmenu, fork of compiz-deskmenu

Hi,

compiz-boxmenu just crashes compiz++ (latest git) when I right-click the desktop sad Any good solutions for that?

Thanks!

Last edited by karabaja4 (2010-12-12 23:05:37)


pie!

Offline

#35 2010-12-12 23:35:19

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

karabaja4 wrote:

Hi,

compiz-boxmenu just crashes compiz++ (latest git) when I right-click the desktop sad Any good solutions for that?

Thanks!

Both compiz-boxmenu and mygtkmenu do that for me. I'm guessing if you use the DesktopClick plugin, it might not happen.

Offline

#36 2010-12-13 00:02:44

karabaja4
Member
From: Croatia
Registered: 2008-09-14
Posts: 840

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:

Both compiz-boxmenu and mygtkmenu do that for me. I'm guessing if you use the DesktopClick plugin, it might not happen.

Yeah, I saw the link above. But I don't know how to install the plugin, if I do git clone of their repository, I get a *.cpp file which I'm unsure how to install (if I try to compile it without any flags it complains about missing files/headers).

Last edited by karabaja4 (2010-12-13 00:03:41)


pie!

Offline

#37 2010-12-13 21:13:07

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

karabaja4 wrote:
pogeymanz wrote:

Both compiz-boxmenu and mygtkmenu do that for me. I'm guessing if you use the DesktopClick plugin, it might not happen.

Yeah, I saw the link above. But I don't know how to install the plugin, if I do git clone of their repository, I get a *.cpp file which I'm unsure how to install (if I try to compile it without any flags it complains about missing files/headers).

I have a PKGBUILD for that lying around on my system for that if that helps. Also, compiz++ is back to working on my system, but I haven't been able to get the commands plugin to run any assigned commands outside of screen/key/etc. bindings. On the bright side, I have been able to make the updates to force the working directory in compiz-boxmenu to always use your home directory and got the windowlist and viewportlist autoupdating again.

Current source tarball version
Current source tarball version with filebrowser

[EDIT] While using the pinned menus feature for a bit, I thought about how the pipeitems were always going to be outdated if I did something while the menu was still pinned. Another issue that I am seeing with pipeitems is that it might take FOREVER for a menu to load if it involves nested pipes. If these pipeitems were pipemenus, this issue wouldn't be a concern. With the upcoming libxml2 parser port, I might have to feed the associated item the menu output, and trigger it upon activation (just like every other pipemenu in lightweight window managers and how this deals with the filebrowser, viewportlist, and windowlist types). The other solution, albeit more complex and most likely implausible would be for the menu that contains these pipeitems to magically find out where they used to be, regenerate them, and then insert them in their proper positions.

But if I decide to make this change, I think I might have to figure out how to make the exec: names update more frequently (like displaying time in a menu, etc), but I'm not so sure about this. An outdated exec: name output isn't as crucial as an outdated pipeitem output though.

Before I attempt this, how many actually have pipeitems that change between menu and item modes depending on the conditions in the pipeitem?

Last edited by ShadowKyogre (2010-12-14 00:27:10)


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

Offline

#38 2010-12-17 22:15:28

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

Another double post yet again, but it's a major update.

I spent some time reworking the pipeitem feature to be pipemenus and it's almost done. I've also reworked the cache feature, which should instead store the generated menu for the file (resulting in near instant popups). It might not be necessary to port to libxml2 after noticing this. I still need to work on importing menu files if a simple 'head bla|tail bla' and cached turned on doesn't suffice this.

Other than that, the changes should be able to be pushed to the git repo.

Current version
Current version with experimental filebrowser

Last edited by ShadowKyogre (2010-12-20 00:08:19)


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

Offline

#39 2011-02-14 19:43:15

Unia
Member
From: The Netherlands
Registered: 2010-03-30
Posts: 2,471
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

Hey there. I was wondering if there's any way of installing this on Ubuntu. When I download the latest version (above post) and then run make from the extracted directory, I get

jente@lappy:~/Downloads/compiz-boxmenu$ make
dbus-binding-tool --mode=glib-server --prefix=deskmenu --output=deskmenu-glue.h deskmenu-service.xml
make: dbus-binding-tool: Opdracht niet gevonden
make: *** [deskmenu-glue.h] Fout 127

Is it even meant to be installed on Ubuntu?

EDIT: Nevermind, had to install some dbus-dev packages. All is working now! smile

Last edited by Unia (2011-02-15 16:12:57)


If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres

Online

#40 2011-02-17 20:15:27

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

Unia wrote:

Hey there. I was wondering if there's any way of installing this on Ubuntu. When I download the latest version (above post) and then run make from the extracted directory, I get

jente@lappy:~/Downloads/compiz-boxmenu$ make
dbus-binding-tool --mode=glib-server --prefix=deskmenu --output=deskmenu-glue.h deskmenu-service.xml
make: dbus-binding-tool: Opdracht niet gevonden
make: *** [deskmenu-glue.h] Fout 127

Is it even meant to be installed on Ubuntu?

EDIT: Nevermind, had to install some dbus-dev packages. All is working now! smile

Glad you got it compiled! big_smile

On another note, I need to package this up as an *.deb and an *.rpm for other distributions. Making the *.deb file will take some time since I've been away from my desktop because of some recent college work, but I should be able to get that in this weekend.

[EDIT]: Made a package just now for it using multipkg: http://sourceforge.net/projects/compizb … b/download . Try testing the package on an Ubuntu or Debian livecd before installing it on your system.

Last edited by ShadowKyogre (2011-02-18 02:38:46)


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

Offline

#41 2011-03-24 17:18:02

Scriptor
Member
Registered: 2011-01-16
Posts: 40

Re: Compiz-boxmenu, fork of compiz-deskmenu

Hi,

I am also interested in not having compiz-boxmenu right-click not just on desktop. So my question is how can I include desktopclick plugin(as mentionned before) in compiz? Or is there better solution

Thanks a lot for any response

Scriptor


The program said:"Install windows 2000 or better" so I installed Linux

Offline

#42 2011-04-02 12:54:21

Unia
Member
From: The Netherlands
Registered: 2010-03-30
Posts: 2,471
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

@ShadowKyogre

Firstly I wanted to thank you for your prepackaged Arch packages which includes all the necessary scripts to have a functional Compiz Standalone Session. I'm using them right now and it made everything just that little easier! Maybe you could make this package available in the AUR? Would be even more easy!

I don't know whether it was an error on my side or on your side though, but the autostart.sh file contained an error.

DESKTOP_ENV="COMPIZ"
if which /usr/bin/xdg-autostart >/dev/null 2>&1 ; then
  /usr/bin/xdg-autostart $DESKTOP_ENV
fi

In that part, the line
if which /usr/bin/xdg-autostart >/dev/null 2>&1 ; then
first looked like if which /usr/bin/xdg-autostart >/dev/null 2>&1) ; then. The ) had to be removed.

Secondly, I don't know how you reboot/shutdown from your Compiz Standalone, but I have edited some scripts found on the Crunchbang Linux boards which gives you the option to do several things:
tODJ5bQ

The Log Out part doesn't work for now, as it relies on fusion-icon which you don't use in your scripts. Maybe when I got time I'll edit the oblogout script, so you have some nice looking buttons instead of the text that it has right now. Anyway, I wondered if you were interested - maybe it can even be added to your Compiz Standalone packages.


If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres

Online

#43 2011-04-03 20:06:19

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

Scriptor wrote:

Hi,

I am also interested in not having compiz-boxmenu right-click not just on desktop. So my question is how can I include desktopclick plugin(as mentionned before) in compiz? Or is there better solution

Thanks a lot for any response

Scriptor

First, you'd need to install it, which is the tricky part if you're running the stable Compiz. I probably need to look at the build instructions for the plugins of the 0.8.x series, as I'm having trouble building those because it says something like "I need CompizFusion" even though it's already installed. When I get a working PKGBUILD for the 0.8.x series, I'll let you know.

For the 0.9.x series, it compiles fine, but it won't work as expected (it will crash your session since it suffers the same bug that the vpswitch plugin has when it tries to call any command from the commands plugin).

Unia wrote:

@ShadowKyogre

Firstly I wanted to thank you for your prepackaged Arch packages which includes all the necessary scripts to have a functional Compiz Standalone Session. I'm using them right now and it made everything just that little easier! Maybe you could make this package available in the AUR? Would be even more easy!

I don't know whether it was an error on my side or on your side though, but the autostart.sh file contained an error.

DESKTOP_ENV="COMPIZ"
if which /usr/bin/xdg-autostart >/dev/null 2>&1 ; then
  /usr/bin/xdg-autostart $DESKTOP_ENV
fi

In that part, the line
if which /usr/bin/xdg-autostart >/dev/null 2>&1 ; then
first looked like if which /usr/bin/xdg-autostart >/dev/null 2>&1) ; then. The ) had to be removed.

Secondly, I don't know how you reboot/shutdown from your Compiz Standalone, but I have edited some scripts found on the Crunchbang Linux boards which gives you the option to do several things:
http://ompldr.org/tODJ5bQ

The Log Out part doesn't work for now, as it relies on fusion-icon which you don't use in your scripts. Maybe when I got time I'll edit the oblogout script, so you have some nice looking buttons instead of the text that it has right now. Anyway, I wondered if you were interested - maybe it can even be added to your Compiz Standalone packages.

I used to use "sudo shutdown" or "sudo reboot" to shutdown my computer until I installed upower and pm-utils so I could just call the upower dbus methods (since my computer has a guest account). However, you don't need to worry about the shutdown issues and that bug in the autostart.sh anymore since I added fusion-icon support in the latest AUR package, which I just put up.

http://aur.archlinux.org/packages.php?ID=47904 <- Here's the AUR package, which will always build whatever updates I push to the git repo for it.

Last edited by ShadowKyogre (2011-04-04 01:52:51)


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

Offline

#44 2011-04-04 15:08:06

Unia
Member
From: The Netherlands
Registered: 2010-03-30
Posts: 2,471
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

ShadowKyogre wrote:

I used to use "sudo shutdown" or "sudo reboot" to shutdown my computer until I installed upower and pm-utils so I could just call the upower dbus methods (since my computer has a guest account). However, you don't need to worry about the shutdown issues and that bug in the autostart.sh anymore since I added fusion-icon support in the latest AUR package, which I just put up.

http://aur.archlinux.org/packages.php?ID=47904 <- Here's the AUR package, which will always build whatever updates I push to the git repo for it.

That AUR package is awesome! Thanks! smile

EDIT: I take it you do not need the script? It uses those upower commands

Last edited by Unia (2011-04-04 15:10:08)


If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres

Online

#45 2011-04-04 19:21:16

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

Unia wrote:
ShadowKyogre wrote:

I used to use "sudo shutdown" or "sudo reboot" to shutdown my computer until I installed upower and pm-utils so I could just call the upower dbus methods (since my computer has a guest account). However, you don't need to worry about the shutdown issues and that bug in the autostart.sh anymore since I added fusion-icon support in the latest AUR package, which I just put up.

http://aur.archlinux.org/packages.php?ID=47904 <- Here's the AUR package, which will always build whatever updates I push to the git repo for it.

That AUR package is awesome! Thanks! smile

EDIT: I take it you do not need the script? It uses those upower commands

Welcome! big_smile

And yes, I don't need the script because I placed the upower commands in my compiz-boxmenu menu.


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

Offline

#46 2011-04-20 22:24:24

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

I haven't been using Compiz for a while. Can someone update me a bit?

Does Compiz .9.2 fix the bug where Compiz crashes when I try to call compiz-boxmenu by right-clicking on the root window?
What about .9.4? Is anyone using that with compiz-boxmenu?

I'm planning on setting up Compiz standalone on my sweet new laptop, but I'd like some confirmation on this first.

Offline

#47 2011-04-21 04:03:25

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

pogeymanz wrote:

I haven't been using Compiz for a while. Can someone update me a bit?

Does Compiz .9.2 fix the bug where Compiz crashes when I try to call compiz-boxmenu by right-clicking on the root window?
What about .9.4? Is anyone using that with compiz-boxmenu?

I'm planning on setting up Compiz standalone on my sweet new laptop, but I'd like some confirmation on this first.

0.8.x Works fine for right-clicking the root window. 0.8.8 came out recently, and the Arch repositories still have to update to that version.
0.9.2 doesn't fix the bug where Compiz crashes by right-clicking the root window if the vpswitch plugin tries to call any command from the commands plugin, including compiz-boxmenu. The code for the vpswitch plugin hasn't changed, so it most likely doesn't work in 0.9.4. The desktopclick plugin suffers a similar bug, given that it calls other plugin functions in a similar way that the vpswitch plugin does.

I can't exactly remember if I showed the debug log or not, but I think I've narrowed down why it does that. See the stuff below the dashed line for more information.
--
Some relevant data:
Lines of interest:
http://cgit.compiz.org/compiz/plugins/v … switch.cpp : 55-56
http://cgit.compiz.org/~smspillaz/deskt … dclick.cpp : 121-123, 136-138
http://cgit.compiz.org/compiz/core/tree … mmands.cpp : 30-48

Compiz debug log from soreau:
http://sprunge.us/VXcd

Backtrace from about a month ago, but it still has valid data since the code hasn't changed:
http://pastebin.com/BSJUp1WB (<- in short, boostlib complains about calling a non-existent function, which is true to some extent since I think it's trying to call whatever the commands plugin uses to call up commands with the wrong number of parameters. Not sure how to fix that, but I think those two plugins will need to find out if they're calling actions from the commands plugin and adjust appropriately or change how the commands plugin runs functions.)


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

Offline

#48 2011-04-22 12:52:44

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

Re: Compiz-boxmenu, fork of compiz-deskmenu

Has anybody made a bug report for this?

I'm pretty hell-bent on using .9.x, so I may just have to live without the right-click menu, which is okay on a laptop anyway. I mostly use dmenu to launch apps, but I'll just also have compiz-boxmenu keybinded.

Offline

#49 2011-04-26 13:05:33

crocowhile
Member
Registered: 2009-10-18
Posts: 54

Re: Compiz-boxmenu, fork of compiz-deskmenu

Does anybody know if there is a way to populate the compiz-boxmenu automatically the way gnome-panel menu does it? I guess one could write a script that looks into /usr/share/applications and write to menu.xml but is there any other "ready to go" way?

Offline

#50 2011-05-01 15:49:03

Unia
Member
From: The Netherlands
Registered: 2010-03-30
Posts: 2,471
Website

Re: Compiz-boxmenu, fork of compiz-deskmenu

ShadowKyogre, do you have any tips on how to get your Compiz-alone-utils package to work with Slim? When I used the old GDM I could just pick its session and off it went, but now with the GDM3 I need another Display Manager so I picked Slim. What would I have to do to get Slim to boot into Compiz standalone?

EDIT: Nevermind, I found it. Made a typo in the ~/.xinitrc. Here's what you have to do:
- Add compiz-alone-session to the sessions line in /etc/slim.conf
- Edit ~/.xinitrc and add exec compiz-alone-session

Last edited by Unia (2011-05-01 16:02:54)


If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres

Online

Board footer

Powered by FluxBB