Moving the menus to the side is a radical idea! I think you would lose too much readability. Perhaps if the whole name showed when you roll over the menu, or if the names of all of the menus showed when you roll over any menu title. As you suggested, I don't think this is something the window manager does, I think it is handled by GTK, in the "Appearance" panel. To achieve this it may be necessary to fork GTK and recompile apps, which would be a major inconvenience.

Edit: maximus does work. There are a couple of options worth noting: --no-restart and --no-maximize
Both are helpful if you just want to try it out. The <Alt>F10 shortcut (found in Window Manger: Keyboard) is how you get a window back to regular size after maximizing.

Stable releases!

Last week-end, our awesome Nick released new stable versions for almost all Xfce major components: libxfce4util, tumbler, xfce4-appfinder, xfce4-session, xfce4-panel, xfwm4, xfce4-settings, garcon, thunar, xfce4-terminal and tumbler (this is not amnesia, we got two releases in a single day for this component!).

I still need to release libxfce4ui 4.10.1 which would fix some keyboard shortcut issues: numpad shortcuts, shortcuts with Shift, shortcuts with Alt+Print... I need some testers for this stable branch before releasing. So grab the code on git or from this tarball and please confirm if it works fine after restarting your session. Thanks in advance for your help.

The list of changes which can be found in those stable releases in available on the Xfce Announcement mailing list. I wish you all an improved Xfce experience!

Xfce Blog

I wonder if the newer versions mentioned in the Xfce blog will make(/allow) Thunar to produce thumbnails for video files? After realizing that (my installation of) Thunar produced neither "picture" thumbnails for video files nor "hover your mouse cursor over the file and listen to a preview" thumbnails(?) for audio files, I tried to follow some directions I found somewhere on the Internet for making Tumbler work - and then tried following other directions for using a different thumbnail component with it (I cannot remember for sure, I think it might have been gtstreamer? Ffmpeg? :shrugs: ), which also failed to work for me. I have since learned that if I run PCFileman and use it to view a directory that contains video files, it will - rather quickly and with no fuss - create thumbnails for the video files. Those thumbnails will then appear every time I view that particular directory with Thunar afterward. However, as "solutions" go, this is unwieldy and doesn't do anything as far as adding the preview capability to audio files (which may or may not actually be "thumbnails," now that I think about it... But Nautilus does it in GNOME 2.x and when I initially noticed that Thunar couldn't seem to create these, either, I assumed that its not being there was part of the same problem).

Hope someone figures it out and helps us non-techies,
MDM

EDIT: I just followed the links to read some release notes on the newer versions of Tumbler. It looks like 0.1.29 addresses "Fix memory corruption on 64bit (bug #9766)." Version 0.1.30 addresses the following:
- Set nice value of tumblerd to 19 (bug #9627).
- Fix rendering from pdfs with thumbnail (bug #9972).
- Add more supported types for gst thumbnailer (bug #9747).
- Some additional debug checks for bug #9766 and minor optimizations.
- Fix deprecating warning with glib 2.36.
- Include string.h (bug #9858).
...but IDK if all that means it fixed it not working for video files or not. I don't really understand half of what I read these days and if I narrow that to "computer stuff" then it probably drops to about a twentieth.

There's also a version of Thunar newer than the 1.6.2 one that is on my system. Its release notes state:
Release notes for 1.6.3
=======================
- Autotools updates.
- Allow keyboard shortcuts for user customizable actions (bug #1941).
- Prepend and later reverse for collecting selection.
- Some optimizations in renamer loop.
- Plug leak in file renamer (bug #9864).
- Escape name for sidepane tooltips (bug #10001).
- Revert "Remove image resolution from statusbar."
- Fix segfault when going back to removed directory (bug #9831).

All three of the above mentioned newer versions also add various languages, I think. I didn't copy/paste those parts because I don't suppose they have anything to do with the issue.

I kicked off on debian with Xfce, knowing it from xubuntu... while I liked it, I didn't stay long, I reinstalled and set up lxde and haven't come off it for a year now.
It's simple and it has openbox which is nice.  check my lxde page on my site for my install notes (which I hope don't have too many mistakes)

First, there is a command that will open the xfce start menu under the mouse, wherever the mouse is. This definitely works for xfce 4.10, and I think 4.8:

xfce4-popup-applicationsmenu -p

Unfortunately I can't tell Plank to execute this command. I have to make a desktop launcher and tell Plank to start that. When I first tried this there was a glitch, which I found a workaround for. Here are step by step instructions:

1. Create a desktop launcher that will open the Application Menu. Paste the text below into your text editor, and save it as:

~/.local/share/applications/appmenustart.desktop

Once you have saved the file, double click on it. Choose "make executable." After that, double click on it again and you should see the xfce app menu appear under your mouse.

[Desktop Entry]
Version=1.0
Type=Application
Name=AppMenuStart
Comment=Open xfce app menu
Exec=xfce4-popup-applicationsmenu -p
Icon=media-playback-start
Path=
Terminal=false
StartupNotify=true
Name[en_US.UTF-8]=Start
OnlyShowIn=KDE;

The line about only show in KDE is to keep this launcher from showing up in the xfce menu, which would be confusing.

2. Create a Plank dock file with the text below. Paste the text below into your text editor, change the username and save it as:

~/.config/plank/dock1/launchers/appmenustart.dockitem

It should show up immediately in Plank.

[PlankItemsDockItemPreferences]
Launcher=file:///home/yourusername/.local/share/applications/appmenustart.desktop

The dock item should appear, but it may not work. I found that it would stop working after I opened the Application Menu on my main panel. When I took the Application Menu out of the panel, nothing worked, not even running the command. So...

3. Make sure the Applications Menu is in a panel, but in a place where it cannot be clicked.

- Remove the Applications Menu from your main panel.
- Make a new panel, put the Application Menu and three separators in this panel, and nothing else.
- Move the panel to an unused corner of your screen. The icon should be closest to the edge, with the separators towards the middle.
- Make the panel transparent (alpha 0), and check "Don't reserve space on borders."
- Make the panel 1 percent in width, and uncheck expand if necessary. The start icon should disappear from the screen.

After doing these three things I have a reliable application menu button in Plank.

If you miss a visible start button in the panel, there is a way to get that functionality back.
Add a Launcher to the panel.
Add a new empty item to the Launcher.
Pick a name and an icon. For the command, use the following:

xfce4-popup-applicationsmenu -p

Save and close out. Both the dock button and the new panel button should work without interfering with each other.

"I probably avoid using the mouse as much as you avoid using the keyboard"
1. Linux+Mouse sucks.
2. Therefore everyone prefers keyboard.
3. Therefore _basic_ Linux+Mouse functionality is never implemented.
4. Therefore 1. (repeat ad infinitum)
My suggestion could be one small step to end this doom loop. At least in xfce.

The lack of Drag and Drop is everywhere in XFCE.
Yes, you can Drag and Drop from the application finder to a panel, but you can't Drag&Drop application inside of it (e.g. to change the categories. Which would be awesome, since "New Items", created in "Main Menu" are ALWAYS put in the "other" category... and "application finder" has not even the commands to Add or Delete applications... wtf?).
You can't drag&drop files/scripts/applications/anything into it (to create application-entries. Preferably in the right category.).
Yes, you can Drag&Drop applications in the panel to change their order... wait... no, you can't.

Windows 95 (!) had Drag&Drop of general items (not only applications) into/from/inside the start menu and panels.
Android's Cyanogen Mod uses Drag&Drop for cool stuff like "Drag and Drop an application onto another. BAM! You get a subfolder containing both applications." Magic...
By now this kind of convenience should be "the basics".

"widget, gadget, whatever"
maybe something like extensions.gnome.org would be cool for XFCE... one-click-to-try-out-platform. Which by itself sparks widget-creation, -sharing and trying.
In the default repositories there are not many xfce widgets.
On the other hand it should not be a widget, since drag and drop is one of the basics.

bwat47 wrote:

the_file wrote:

Drivers do make the major difference but the hardware that powers things do to. Anyhow compiz is just a very good and usefull window manager; which I hope will be completely ported to wayland. Also I hope xfce will be ported to run on top of wayland natively.

In the case of intel its both the hardware and the drivers. Recent intel hardware is designed with a compositor in mind, the reason for this is power-saving. I wouldn't be suprised if this becomes the trend for other graphics hardware too, proper compositing is the future, even for a lightweight environment: here is a quote from an intel devleoper:

First note that all Intel hardware up to SandyBridge has functional vsync support with no greater cost than stalling the GPU until the blit can proceed.

The problem is that with the agressive powersaving of SandyBridge and the greater decoupling between the display engine and the GPU, the ability to delay rendering until a particular scanline had passed was assumed to be a legacy feature and the GPU commands to do so were removed. By presuming that all updates would then be through a compositor using pageflipping (i.e. their primary target, Windows Vista/7/8), they were then able to make further power savings. If you use an OpenGL (really DRI2) compositor that only pageflips (i.e. doesn't try to take "advantage" of MESA_copy_sub_buffer), you will not see any tearing, suffer very little jitter, and maximise the power savings of the GPU.

The TearFree option (still in its infancy, and really only a proof-of-principle at this stage) is to make sure that even a bare X only ever pageflips. This is primarily because future hardware will have even more widespread aggressive power savings that assume a compositor, and worst case scenario, the display engine will only be functional with a pageflipping compositor.

Seems like Intel is doing more to save power than trying to power the apps its supposed to run.

Intel GPU's are designed to be power efficient to be used in laptops and such.

Its also worth noting that its not just hardware thats being designed with compositing in mind, but software too: X's sucessor, wayland, is designed from the ground up with composting in mind.

Update - After that quick reply I read the script more closely and see that it doesn't just set the theme, it toggles between two, which is even better. Thanks!

MagnusBerg wrote:

hoagie wrote:

Heres an interesting read regarding toolkits from one of the lxde developers: http://blog.lxde.org/?p=990

... and some older stuff about theme etc.-breaking: http://igurublog.wordpress.com/2012/11/ … in-threes/

I read the last link and was scared. The blog post has a year on it's shoulders and I hasn't followed the Gnome developers latest steps but if it continue as written in the blog post there are reasons to boycott Gnome. And there are reasons to port Xfce4 to Qt. Reading the first link gave a little impression that LXDE are going to be Qt based in the future. The LXDE developer has written a migrate from Gtk+ to Qt guide. http://wiki.lxde.org/en/Migrate_from_GTK%2B_to_Qt

PCMANFM the guy behind lxrandr port to QT in 1 day and PCManFM-qt port a(ANd the majority of LXDE)say that programing for GTK3 is a nightmare compared to QT that is pleasant
her drop those words beffore end the porting of pcmanfm-qt

at this point I think that is best hear a words from anyone of the devs because, users can say 1000 words but dev are the only one that have dirty hands and know how this really work

Seems like a lot of devs are claiming that GTK is messy and dirty to code. Sure the UI looks nice but if the code is bad then it will lead to trouble.

Perhaps someone should fork GTK, since GTK is virtually not changing very much with every release.

Fedora 18

Wow, you've convinced me to switch. 

The other thing is a rule/policy that the panel should always be on top. This can be changed at runtime using the wmctrl tool, as described here:
https://bbs.archlinux.org/viewtopic.php?id=138592

If you search for wmctrl and xfce panel you will find some of variants on that script. Having the panel always on top may be the more popular setting, but clearly some people like it better the other way.

You can also run this and then click on the panel window, that makes it behave like a normal window which is what I prefer:
xprop -f _NET_WM_WINDOW_TYPE 32a -set _NET_WM_WINDOW_TYPE _NET_WM_WINDOW_TYPE_NORMAL

To me the "don't reserve space" setting is stupid when the panel is always on top, why would I ever want to maximize my window and have it partially behind the panel? Would make more sense if this settings combo made the panel appear on bottom.
"don't reserve space" and autohide on the panel might work. I personally don't like autohide because I wan't to be able to see my clock without moving my mouse.

Someone's complaint about panels and later an answer from the developer why they don't think this should be changed.
http://mail.xfce.org/pipermail/xfce/201 … 31743.html

Possibly related:
https://bugzilla.xfce.org/show_bug.cgi?id=7620

The funny thing about roadmaps - in terms of software development - is that the only real way to create one that is 100% accurate is to wait until your "journey" is completed, and produce an after-the-fact record....

@MountainDewManiac

Thank you for your answer. I only felt pity of that excelent desktop env. had been suffering lack of developers. There must be some reason though!

-Does it suck?!
-No

-Is it so buggy, heavy that nobody wants to join the project?
-No

-Is it ugly, ascetic - only 4 geeks?
-No

-Is it ergonomic?
-Definitely!

So what is the reason? Well, in my opinion an "open" source project needs to be open not only by giving a public access to the code, but by spreading  information about it.
The roadmap in particular is a setting a goal (challenge) where a team aims to. Is a challenge ambitious? Is it valuable? Is it nice to be in a team to accomplish that goal?
What can I learn in order to accomplish it? And so on...
So I'm looking at it not only from user's point of view, but from a potential developer. What does a potential developer consider when he/she joins a project?
The goal is not a thing literally that must be done in every single aspect. It has rather more psychological impact. It is like a light at the end of a tunnel, small star on the sky as direction on the ocean
Simply: it shouldn't be neglected, even we can't fulfill all the features we set before.

What do you think, MountainDewManiac?