Panel context menus redesign

[jleclanche]

See https://groups.google.com/forum/?fromgroups#!topic/razor-qt/iVN1z_a_qr0

[falde]

What about adding a "restart razor"? This would be useful when playing around with configuration. It would also be useful if some bug makes parts of razor hang, it hasn't occurred for me but nothing lasts forever.

Perhaps this should also be in the desktop context menu?

[jleclanche]

In debug mode there's already an exit panel, if you want to restart all of razor you can write a script.

[falde]

How do I enable debug mode then? And doesn't that do a lot of stuff i wouldn't want in a production environment?

How do i write a script that is run from the context menu? Naturally I do know how to write a scripts that restarts razor but I was talking about doing it from the GUI...

[dcu]

I would go for OSX panel approach. those windows-like panels are obsolete and awful.

[jleclanche]

@falde This is not something you want here

@dcu there are plenty of osx dock apps around, it's not something you'd want razor to ship

[dcu]

the problem with those dock apps is that they don't feel like part of desktop. the look good but they don't feel good. why do you think copying windows approach is better than copying OSX?

[jleclanche]

Razor is meant to be lightweight above all, and a dock just doesn't fit in that approach. And please consider that not everyone likes docks, it's also a matter of preference.

What I'd be fully for, however, is blessing a pure-qt dock and getting it to integrate nicely.

[dcu]

actually a dock is probably lighter than a full panel + menu. Lion dock doesn't even have magnification enabled by default, for example.

it's just a list of icons, I can't think of something lighter than that.

[dcu]

You'll never make everyone happy but the panel is something that marks the first experience with the desktop and what Linux desktops have is far from good for newcomers and advanced users. Hiding the apps in awful trees behind a button is worst thing you can do. EDIT1: the only desktop in which this work is windows only because people know the app names, otherwise they would be lost. instead of that you should expose the apps! let people find and launch file browser, internet browser, app launcher, mail app, music/video player, system preferences and their most used apps in one click, without delays or hassles

think about it.

[jleclanche]

This bug has really nothing to do with it, feel free to bring it up on the mailing list though.

[falde]

@Adys Yes I do. I had it for 10 years in LiteStep and it was wonderful. @dcu A dock panel app that could be used instead of the task list may be an option in the future. A start menu is very easy to learn so it should stay, so should the standard task bar.

We have a quicklaunch panel app and perhaps it should be easier to add more stuff there. Standard apps like browser, mail and office apps should be there, all using Xdg defaults. At least it should be possible to turn that on.

[jleclanche]

Sorry, sent my message before typing it fully. What I meant is, a "restart razor" is not something you want in a production environment, so might as well stick to debug mode.

[falde]

@Adys Actually I do. Why not just make it optional and let admins decide if they want it?

[jleclanche]

Because in debug mode there already is an "Exit " context menu item.

[falde]

@Adys How do I enable debug mode globally in my production environment then?

[jleclanche]

-DCMAKE_BUILD_TYPE=debug at cmake time

[falde]

So I would have to build my own binaries to enable one feature?

[jleclanche]

Yes, as this is a debug feature... production is not supposed to have it.

[falde]

But the point is that I want it in a production environment. What would be the problem with making it optional trough a config file instead of at compile time?

[jleclanche]

It's confusing, and in general it's absolutely not something you want in production. If you want to restart razor, as a simple user, you logout and log back in. If you really just want to restart the razor processes, killing the processes works since they're automatically restarted.

[falde]

My users are not simple... Logging out and in requires restarting all applications and takes a lot of time. Using killall -HUP in a terminal is what we currently do. Having a menu option is far more production ready then using killall in a terminal.

[amoskvin]

falde, you're not providing a compelling reason why you want to restart Razor. If it's so buggy that you need to restart it frequently, we want to know about it ;)

[falde]

@amoskvin I have previously used both KDE and Gnome in my production environment. Currently I am using LXDE and plan to switch to razor. My experience with all these desktop environments is that bugs that require kill -HUP will occur at some point. With LXDE more frequent then the others.... Even if razor seams more stable I go with the better safe then sorry philosophy...

Also razor do not reload theme settings when they are changed nor do it restart automatically when updated to a new version trough the packet manager.

[jleclanche]

The problem is still the same: you don't want users to be able to restart razor like they're making cheesetoast. Devs? Sure. Thats why theres debug mode.

[falde]

Then why don't make it optional and disabled by default? Or perhaps a generic way for sysadmins and users to add stuff in the menu in the config files.

[jleclanche]

I don't know how I can be any clearer: the option exists in razor debug mode. It's not available in production at all because it's not something users would want to do (not just from a design POV, but also from a technical one).

[falde]

@Adys Thats it not something users would want to do is a quite big assumption and I think i know my users better then you do. Perhaps it is something YOU do not want the users to do.

But fine I get it. I will have to fork and build my own razor packages before rolling it out in my production environment.

[jleclanche]

As I said it's not just an assumption, it's also something we wouldn't want users to do. Especially from a CONTEXT MENU! A misclick and all of a sudden your apps are gone - what?

[falde]

How would restarting razor kill all apps? That does not happen when I do it with killall -HUP... Are you saying that the menu option in the debug mode means "Logout"?

Logout is already on the start menu and on the desktop context menu so obviously that do not need to be added.

To be clear. What i want is the equivalent of killall -HUP, which should NOT close applications.

[jleclanche]

Right. So you want the debug option... so build in debug mode? :P

Debug mode doesn't even add anything relevant other than that apart from debug symbols.

[jleclanche]

I just want to explain my position on this a little further: Restarting razor is something you would want to do because of either a very-fast-paced development cycle (running off git) or regular bugs (developer). Both those cases are perfectly valid "debug mode" use cases.

Restarting razor itself is confusing to an user, because they would expect a logout action. Most users don't even make the difference between Logout and Shutdown.

I totally understand the feeling though, what I recommend is creating a desktop script, that way you can run it off razor-runner (kill-razor.desktop -> alt+f2 kill)

[falde]

@Adys I will go with the fork and add my own menu options instead. Possibly i will make the menu totally configurable so I can add a menu option that call a script somewhere in /etc

It pends a lot on what user you have and I would say that most of mine recognize the difference between different logout options.

[SokoloffA]

@falde The panel apply the settings on the fly. Version from the git reload theme too. So we no need to use "restart panel" menu.

Just now you can restart panel running $ killall razor-panel

The razor-session monitors the panel and launch it.

You can even add it to the main menu. Create file ~/.local/share/applications/razorpanel-restart.desktop with next content

[Desktop Entry] Type=Application Exec=killall razor-panel Icon=system-shutdown Terminal=false OnlyShowIn=X-RAZOR; Categories=Qt;System;X-RAZOR; Name=Restart panel

[pvanek]

my 2cents:

• ad panel: I'm mac user too and the dock is one of things I really hate in OS X. But (and it's important) I don't have anything against including it as a eg. new panel plugin if somebody will write it.
• ad "restart": the only usecase for restarting panel/desktop I can see is the development. All other reasons are bugs. And remember that when you exit eg. panel cleanly (exit(0)) the session won't catch it for restart. Only crashes or != 0 exit statuses are taken in this case.
• ad "menu redesign": I vote for it. These multiple-level menus are too complex for me.

[falde]

@SokoloffA: Did that now... but it has to be in /usr/local to be available to all users. I would prefer to have it under "leave" but there its not used often enough to motivate me to create a fork just in order to place it where I want it. Its available now and that's whats important. Also i made a script that kills bot the panel and desktop with -HUP.

@pvanek: On the ad panel i fully agree. On the restart, see above - this feature is already fully supported without any need to modify the panel sourcecode. On context menu redesign i vote for it.

[SokoloffA]

@falde

Did that now... but it has to be in /usr/local to be available to all users.

You can put it in ~/.local/share/applications/ for personal use, or in the /usr/local/share for all. I would prefer to have it under "leave". Now you can't has it under "leave", this it not real menu, this hardcoded submenu.

but there its not used often enough to motivate me to create a fork just in order to place it where I want it. Its available now and that's whats important. Also i made a script that kills bot the panel and desktop with -HUP.

The only sense to have the item "reload" - this is a bug in the themes handling. This bug is fixed in the development version. Maybe you would like to use version from the git instead to fork?

[falde]

@SokoloffA As I see it the only "fix" i would require compared to what is currently supported in the production version is to modify the currently hard-coded menus in some way.

To hard-code a reload item in the menu would be a less flexible solution so therefore i withdraw that suggestion.

[SokoloffA]

https://github.com/Razor-qt/razor-qt/commit/36d0c7df71e71a126b44a4de7fd1749393f43924

[amoskvin]

That looks really nice! :)

[pvanek]

what about to remove "Plugins" submenu and merge plugin's "move" and "delete" actions into the toplevel one?

[SokoloffA]

what about to remove "Plugins" submenu and merge plugin's "move" and "delete" actions into the toplevel one?

I tried, but this looks ugly - http://s7.postimage.org/6afe0q7kr/menu.png

[pvanek]

hehehe, it really looks more than strange. But I thought (humble and pathetically expressed) that the topmenu "Plugins >" will disappear completely. Because it has no meanings here now. (at least for me - it was really confusing from the beginning)

[jleclanche]

Thanks a lot for the work. Keeping the issue open as there are a couple of missing changes, but feel free to close it if you feel it's done.

[amoskvin]

There's one possible use case - when trying to move or remove a plugin that has its own menu, like the Task Manager (when full) or Quicklaunch

I guess something like this would be nice: http://i.imgur.com/nD5Jv.png

[pvanek]

Question: is it still the issue now? Git master contains really nice implementation now. What about to close it?

[jleclanche]

Yeah looks good, closing