q4wine-next: call for ideas suggestions or comments

[brezerk]

Hello.

q4wine project was started about 8 years ago. It still continue to evolve from an simple 7-lines 'Hello World' application written just for fun in late 2008 :)

It was a long run. I am really impressed with OpenSource development model. Unfortunately, q4wine has a lot of design issues and limitations. It is really hard to support and add new features. To get rid of this, I am planning to rewrite it completely from scratch.

I do have some new ideas to try, but it will be nice to hear ideas, suggestions or comments from the end users.

So it's my call to you: if you have something to say I'm ready to listen.

[tehnick]

Well, current version of q4wine more or less works. Main functions work fine: user may choose which wine version to use for launching program, user may create desktop files by few mouse clicks, etc. I see a problem with process explorer, but this is fixable.

I do not know which additional features could be implemented in q4wine.

From developer point of view it might be interesting to rewrite GUI from QtWidgets to QML. This is a popular tendency now as I see. But personally I do not like QML and UI based on it. Probably this is due to lack of experience with it.

[pchome]

ok, here is some suggestions:

1. GTK+ interface

maybe some code split will lead to this: CLI, API, GUI ... (which mostly exists), this even allow to create Web-interfaces, if someone need them (playing game on tv and control via mobile?)

2. Gnome "Games" like launcher

q4wine menu tree in App menu is good, but such launcher in Games category will be useful too

3. Plugins

can be useful, for example AppDb/Logging/winetricks parts as default plugins

4. Default prefix settings or special prefix as template

some users need to configure every prefix with same registry settings (ex. VideoMemorySize) or install same software in each new prefix

5. Tools for prefix cleanup

each new prefix - ~300Mb for now, but contains some files which are the same:

• drive_c/windows/Installer/* - different names but same content, 1-50Mb each one
• drive_c/windows/mono/ - WINE's mono version, can differ depend on wine version, ~100Mb
• drive_c/windows/system32/gecko/ && drive_c/windows/syswow64/gecko/ - current gecko version, ~50Mb (~2*50Mb for 64bit prefix)
• drive_c/windows/Microsoft.NET/ && drive_c/windows/winsxs/ - not noticeable for default prefix, but almost the same for prefixes w/ .NET and/or directx/vcrun* installed

usually I symlinking mono and gecko folders to my own, containing all versions of them from previously installed wine versions sometimes same actions w/ Installer files, but this requires more work to compare them (I had an script some time ago, but now it lost) so for 10 prefixes you can save 2Gb disk space tmp files and logs in prefixes can be dropped too, periodically

6. Allow native games in collection

in combination w/ Launcher and simple configuration tool to set __GL_THREADED_OPTIMIZATIONS/LD_LIBRARY_PATH/_other_usefulenv it will be cool

[brezerk]

hi @pchome,

Thanks for a feedback. I like your ideas.

It is not a first time I was asked about Gtk version :) So ok. I am going to try to re implement q4wine lib without Qt dependency.

[ghost]

It would be nice to be able to manage the right-click run targets by prefix. Once you run something it sticks there without (an obvious way) of being modified.

edit: I confused this option as adding a new icon in the system view. Maybe add this option to the right click prefix options?

[tehnick]

Hi,

It is not a first time I was asked about Gtk version :)

I would not recommend to waste your time for GTK+ port of program.

GTK developers currently do not respect FOSS community outside of "GNOME world". Few quick examples: https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ https://bugzilla.gnome.org/show_bug.cgi?id=735211 And this is only a part of whole picture...

So ok. I am going to try to re implement q4wine lib without Qt dependency.

If you really want to provide alternative UI, based on other toolkit, I would recommend to look at EFL or SDL. Even freeglut features might be enough for a light UI.

[tehnick]

I know a number of projects where developers decided to stop develop GTK+ port of programs or even decided to rewrite programs to Qt 5.x. because of a lot of broken things in GTK+ 3.x.. Even our not much known project EiskaltDC++ was affected by GTK 3.x "improvements" so I have faced with them directly.

Sorry for offtopic.

[ghost]

Qt integrates better across environments in the look and feel department.

[brezerk]

hi @tehnick, thanks for the info. Well. Anyway, removing Qt dependency from the q4wine's shared library is a good idea. As for Gtk+... I'll play around it a bit. But Qt gui will remain at my primary focus for sure.

[brezerk]

hi @ryux2.

It would be nice to be able to manage the right-click run targets by prefix. Once you run something it sticks there without (an obvious way) of being modified. Maybe add this option to the right click prefix options?

Sorry but I don't get your point... are you talking about 'Run' dialog?

Both prefix tree and icon view does have run menu option:

And the Run dialog itself does allow you to choose the prefix:

[ghost]

Sorry for the confusion. I was using the 'Run' action thinking it was the option to create a shortcut launcher. Then I found that option was under the content view of the system folder.

What I meant by the edit is that after you've 'Run' an executable and selected a prefix, that run action is visible for every list item in the sidebar. The suggestion is to make it context aware (show only the run actions for the selected prefix). I also couldn't find how to remove them from the list.

With that, also adding the 'New' action of the system folder view to the right-click sidebar list menu as 'New Launcher' or something.

[brezerk]

hi @ryux2, thanks for clarifications.

[Xylemon]

I've been using Q4Wine for years and I think its dependency on Qt4 or Qt5 is fine. Two things I'd personally like is to be able to handle .msi files from the Run dialog and for the comments in my q4wine desktop files to show up in my DE.

[brezerk]

hi @Xylemon.

to be able to handle .msi files from the Run dialog

Added: https://github.com/brezerk/q4wine/commit/283ddf49361197145a8d378e9dd9317fda42f002

and for the comments in my q4wine desktop files to show up in my DE

Fixed: https://github.com/brezerk/q4wine/commit/5f9b712b77a1cf318e9f4079a68c28900ed0a128

[s8321414]

I think split lib and gui part is great, that make q4wine more modular. For gtk version, we have playonlinux, not?

[pchome]

For gtk version, we have playonlinux, not?

yes, but (as for me) playonlinux overdosed with wizards, endless "Next>" buttons ... and there is not pure GTK+ but wxGTK, so on my XFCE desktop I prefer q4wine with qt4 and simple configuration dialogs

p.s. I had not even noticed before : PlayOnLinux 5: Current state

[Xylemon]

@brezerk Thanks a bunch! Will definitely try this out!

[Xylemon]

@brezerk OK I just got around to testing the latest commits, and the desktop file comments still don't show up on my DE (XFCE4). It seems q4wine writes them to "GenericName" when the comments should be in the "Comment" field, at least that's how it would work on XFCE4.

[brezerk]

hi @Xylemon, woops. Fixed. Thanks for checking.

[Xylemon]

@brezerk Thanks a bunch! Works perfectly.

[Ruedii]

A modular design would be ideal.

It makes maintenance a lot easier.

[s8321414]

I am wondering how CLI interface will go? just "q4wine blah blah" like pure wine or ncurses?

[brezerk]

@s8321414 In first place it will be implementation of existing q4wine-cli command. So yeah, it will be "q4wine-cli blah blah" :) Maybe with some kind of interactive CISCO-like CLI interface using http://clish.sourceforge.net/ library.

On the other hand, I was thinking about ncurses interface as well: https://github.com/brezerk/q4wine/tree/next/src/curses

However, It will be developed on the later stages, since I don't think I will have enough time for it.

General plans for 'next' branch are:

First stage:

• q4wine-lib
• q4wine-qt
• q4wine-cli

Second stage:

• q4wine-gtk

Optional components:

• q4wine-curses
• q4wine-efl

Unfortunately I can't give any time estimates right now. I just got a new job, so I will need some time to adopt for a new project.

[Artoria2e5]

@pchome: Not pure Gtk but wxGTK...

Actually wxWidgets can look nice and native if the library is compiled against the version of gtk other parts of the system is using -- gtk3 in most cases for modern systems. See https://bugs.archlinux.org/task/48145.

(In order not to see results like what audacity is showing, try not to hardcode item pixel sizes.)

Nice and Native wxMaxima, screenshot by m13253: https://cloud.githubusercontent.com/assets/6459309/14908181/c2d3a5be-0da1-11e6-9e44-cd695081f206.png What happens when you hardcode element sizes in wx and encounter a backend with big elements: https://cloud.githubusercontent.com/assets/6459309/14908206/31b2f278-0da2-11e6-9f75-6477ddbb2202.png

[pchome]

@Arthur2e5: Actually wxWidgets can look nice and native

Yes, but application like q4wine (or even PlayOnLinux, AFAIK) don't need any special widgets or unique wxWidgets features. Pure GTK+ is enough to display check-boxes/lists/etc.

Just one more big library in system memory = less RAM available for wine application ;)

[Artoria2e5]

Pure GTK+ is enough to display check-boxes/lists/etc.

Using wx means ability to use different backends including Mac, Gtk, and Qt (as well as plain X11 for retro users, plus W32 for Wine-On-Windows users). That's efficient for bringing near-native support to users. Like the one-ui-for-each-toolkit solution, users only using Gtk+ (such users do exist on Linux) can enjoy q4wine without having to spend lots of disk space installing Qt.

Just one more big library in system memory

wx is generally slim in terms of size and resource consumption IMHO...

[brezerk]

@Arthur2e5 wx sounds like fun. Will definitely play around it to see how it looks like. Thanks for the info.

[s8321414]

And maybe consider to support Wayland and Mir on Unix-like system?

[Artoria2e5]

Since wine can't work without X, i doubt if that is really necessary. Anyway as long as there is a Gtk version we can have good Wayland support.

[s8321414]

Qt also improved Wayland and Mir support :stuck_out_tongue:

[ghost]

Any plans on using Qt5 over 4?

[brezerk]

Hi @ryux2 it is possible to build q4wine with Qt5 right now. Just pass -DQT5=ON option to cmake. Or push your pkg maintainer :P

[ghost]

Hello, is there any way to open file in wine program, not just open program? For example, if i want to open document with MSO Word from file manager dialog.

[brezerk]

Hi @Svadkos . Um..

Yes I guess so. It is possible to open files via wine start /ProgIDOpen wine command.

Here you are example of opening *.doc via embedded wordpad program. env WINEPREFIX="/home/brezerk/.wine" wine start /ProgIDOpen rtffile %f

I think it can be updated for MSO W in some way.

btw: there are some interesting options as well https://wiki.winehq.org/Start

[ghost]

Well, actually i mean start file through icon that q4wine create. /usr/bin/q4wine-cli -p "office" -i "Word" and than it just start new empty document, skipping all arguments that follow.

[brezerk]

i.c. I'll take a look on it.

[brezerk]

Hi @Svadkos I was able to fix the issue. See https://github.com/brezerk/q4wine/issues/78 for details. Thanks.

[mdeguzis]

Instead of having to create a folder called "programs" in my prefix on the left side and right click > new icon to add my installed program, add this automatically after installation. Maybe it's not possible right now since I installed Steam via winetricks? Also managing different win versions doesn't seen that intuitive. Why can't there be a selection to install from instead of setting custom paths?

[brezerk]

Instead of having to create a folder called "programs" in my prefix on the left side and right click > new icon to add my installed program, add this automatically after installation.

If the application creates *.desktop files in the /dosdevices/c:/users/$USER/Desktop then it is possible to import this into q4wine via Ctrl + I or Tools -> Import Wine Desktop Files. They will be created in the import folder for respective prefix.

Also managing different win versions doesn't seen that intuitive. Why can't there be a selection to install from instead of setting custom paths?

Not really sure what do you mean here. Can you clarify please?

[mdeguzis]

The last bit there was essentially my feature request of downloading and using Wine binaries.

[Yaksinikos]

How about make a .appimage

[brezerk]

Hi @Translator5 are you talking about http://appimage.org/ ? I can take a look into this.

[Yaksinikos]

Yes I am. :)

[probonopd]

Hi @Translator5 are you talking about http://appimage.org/ ? I can take a look into this.

One option would be to build on Travis CI and package up the build artefacts using linuxdeployqt -- see the Travis CI examples linked there. Basically linuxdeployqt -appimage can do it automatically for you. This option is especially interesting for continuous builds, because every commit on GitHub will result in an AppImage.

Another option would be to repackage existing deb/ppa builds. This may be easier for stable builds.

See https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages for more information.

[brezerk]

@probonopd thanks a lot! Will take a look over the weekends.

[Tatsh]

Please name the icons under system, respecting locale too. For en-US:

Command	Name
control	Control Panel
eject	Eject Disc
explorer	Explorer
iexplore	Browser (to avoid trademark/copyright issues)
notepad	Notepad
oleview	OLE Viewer
regedit	Registry Editor
taskmgr	Task Manager
uninstaller	Uninstaller
winecfg	Configuration
wineconsole	Console
winemine	Minesweeper
wordpad	WordPad

Consider making the new prefix directory without spaces. This just makes it more convenient in case you need to use the prefix in a shell with tab expansion, quoting issues, etc. Example: 'Cool Prefix' becomes /home/tatsh/.local/share/wineprefixes/cool-prefix.

Also add an option for respecting DPI scale. I always get 96 DPI by default and I have to manually change it every time I create a new prefix.