Hey,
I've been thinking about packaging dwm [1] since we already ship dmenu and dzen2. I wonder if anybody would be interested in this fine window manager (except for me).
The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc). In my opinion, we could do it like this:
- install a Fedora preconfigured version along with dwm sources - copy its configuration (C header file) to some fixed location for user to customize - provide a script to recompile dwm locally using the local configuration file
Would this be acceptable for a window manager in Fedora? Would anybody be interested in this? :)
Thanks, Petr
2010/10/13 Petr Sabata psabata@redhat.com:
Hey,
I've been thinking about packaging dwm [1] since we already ship dmenu and dzen2. I wonder if anybody would be interested in this fine window manager (except for me).
The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc). In my opinion, we could do it like this:
- install a Fedora preconfigured version along with dwm sources - copy its configuration (C header file) to some fixed location for user to customize - provide a script to recompile dwm locally using the local configuration file
Would this be acceptable for a window manager in Fedora? Would anybody be interested in this? :)
Well i have packages here of dwm and wmii. Personally i like both of them but the default configuration has the problem that the default key for triggering functionality doesent work in all keyboard mappings. wmii is probably easier to package. if you need help with that drop me an email.
kind regards, Rudolf Kastl
Petr Sabata wrote:
I've been thinking about packaging dwm [1] since we already ship dmenu and dzen2. I wonder if anybody would be interested in this fine window manager (except for me).
I think it's completely unreasonable to package that software, because of this:
The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc). In my opinion, we could do it like this:
- install a Fedora preconfigured version along with dwm sources - copy its configuration (C header file) to some fixed location for user to customize - provide a script to recompile dwm locally using the local configuration file
Such a program is basically not packagable.
Kevin Kofler
On Thu, 2010-10-14 at 01:48 +0200, Kevin Kofler wrote:
Petr Sabata wrote:
I've been thinking about packaging dwm [1] since we already ship dmenu and dzen2. I wonder if anybody would be interested in this fine window manager (except for me).
I think it's completely unreasonable to package that software, because of this:
The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc). In my opinion, we could do it like this:
- install a Fedora preconfigured version along with dwm sources - copy its configuration (C header file) to some fixed location for user to customize - provide a script to recompile dwm locally using the local configuration fileSuch a program is basically not packagable.
It can't be packaged in the sense of shipping binaries. But if a wrapper script is provided that automatically recompiles dwm for the individual user whenever necessary, the software could be packaged in the sense that it could be installed and updated with yum and would be functional without user intervention. The latter is my definition of "packageable". Compare to the akmods offered by RPM Fusion.
Matt McCutchen matt@mattmccutchen.net wrote:
It can't be packaged in the sense of shipping binaries. But if a wrapper script is provided that automatically recompiles dwm for the individual user whenever necessary, the software could be packaged in the sense that it could be installed and updated with yum and would be functional without user intervention. The latter is my definition of "packageable". Compare to the akmods offered by RPM Fusion.
This is something like XMonad. XMonad, the code, is really just a library for writing your own window manager. A default is provided and a tool to manage the building of the actual window manager executable is offered. Whether upstream will accept such a tool is the question. If not, it can probably be maintained in a separate repository (dwm-manager which Requires: dwm-devel, dwm Requires: dwm-manager to get out-of-the-box support).
We do something similar for uzbl which is also in a similar boat (though without the compilation step).
uzbl -> default settings (uzbl-tabbed and uzbl-defaults) uzbl-core -> main program uzbl-browser -> default tools to get a basic browser (what I use with custom configuration) uzbl-tabbed -> tabbed browsing uzbl-defaults -> default configuration and scripts (Requires: on tools used go here)
Hope this helps.
--Ben
On Wed, Oct 13, 2010 at 09:34:22PM -0400, Matt McCutchen wrote:
On Thu, 2010-10-14 at 01:48 +0200, Kevin Kofler wrote:
Petr Sabata wrote:
I've been thinking about packaging dwm [1] since we already ship dmenu and dzen2. I wonder if anybody would be interested in this fine window manager (except for me).
I think it's completely unreasonable to package that software, because of this:
The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc). In my opinion, we could do it like this:
- install a Fedora preconfigured version along with dwm sources - copy its configuration (C header file) to some fixed location for user to customize - provide a script to recompile dwm locally using the local configuration fileSuch a program is basically not packagable.
It can't be packaged in the sense of shipping binaries. But if a wrapper script is provided that automatically recompiles dwm for the individual user whenever necessary, the software could be packaged in the sense that it could be installed and updated with yum and would be functional without user intervention. The latter is my definition of "packageable". Compare to the akmods offered by RPM Fusion.
I suppose rebuilding for every individual user would also be possible. I guess the best way to do that without any user intervention would be to rebuild every time a user's X session is started -- it's so small one would hardly notice it.
I created this draft based on my yesterdays email: http://psabata.fedorapeople.org/dwm/dwm-5.8.2-1.fc13.src.rpm
However, there are some limitations when compared to your approach: 1. One has to manually call dwm-reconfigure to rebuild dwm with their configuration 2. All users in the system share the same settings (this is worse)
So, the new idea:
package dwm: - installs binaries with default configuration only - depends on dmenu and xterm package dwm-user (or whatever): - installs dwm sources and a "dwm-start" script which: - checks for, say, ~/.dwm.config.def.h; runs default dwm if it's not present, or recompiles dwm in ~/.dwm with the user configuration and runs it if the config's there (and possibly has changed since the last time) - depends on dwm, gcc, make and Xlib-devel
Petr
-- Matt
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Oct 14, 2010 at 10:18:07AM +0200, Petr Sabata wrote:
It can't be packaged in the sense of shipping binaries. But if a wrapper script is provided that automatically recompiles dwm for the individual user whenever necessary, the software could be packaged in the sense that it could be installed and updated with yum and would be functional without user intervention. The latter is my definition of "packageable". Compare to the akmods offered by RPM Fusion.
I suppose rebuilding for every individual user would also be possible. I guess the best way to do that without any user intervention would be to rebuild every time a user's X session is started -- it's so small one would hardly notice it.
I created this draft based on my yesterdays email: http://psabata.fedorapeople.org/dwm/dwm-5.8.2-1.fc13.src.rpm
However, there are some limitations when compared to your approach:
- One has to manually call dwm-reconfigure to rebuild dwm with their configuration
- All users in the system share the same settings (this is worse)
So, the new idea:
package dwm: - installs binaries with default configuration only - depends on dmenu and xterm package dwm-user (or whatever): - installs dwm sources and a "dwm-start" script which: - checks for, say, ~/.dwm.config.def.h; runs default dwm if it's not present, or recompiles dwm in ~/.dwm with the user configuration and runs it if the config's there (and possibly has changed since the last time) - depends on dwm, gcc, make and Xlib-devel
Ok, here it is: http://psabata.fedorapeople.org/packages/dwm/dwm-5.8.2-1.fc13.src.rpm
Comments welcome.
Petr
Petr
-- Matt
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- Petr 'contyk' Sabata, Red Hat, Brno
() ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Matt McCutchen wrote:
It can't be packaged in the sense of shipping binaries. But if a wrapper script is provided that automatically recompiles dwm for the individual user whenever necessary, the software could be packaged in the sense that it could be installed and updated with yum and would be functional without user intervention. The latter is my definition of "packageable". Compare to the akmods offered by RPM Fusion.
Akmods are a horribly ugly hack which is a very bad example to follow. (In fact, I strongly recommend against using akmods, the binary kmods follow packaging best practices much more.)
Kevin Kofler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/13/2010 02:04 AM, Petr Sabata wrote:
The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc).
Am i the only one that finds it hilarious that this thing is named "Dynamic Window Manager"? So dynamic, you gotta recompile to change anything....
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On 10/14/2010 01:13 AM, Jesse Keating wrote:
On 10/13/2010 02:04 AM, Petr Sabata wrote:
The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc).
Am i the only one that finds it hilarious that this thing is named "Dynamic Window Manager"? So dynamic, you gotta recompile to change anything....
I dunno, it sounds a lot easier than reconfiguring some window managers!
;-)
Andrew.
Jesse Keating, Wed, 13 Oct 2010 17:13:43 -0700:
Am i the only one that finds it hilarious that this thing is named "Dynamic Window Manager"? So dynamic, you gotta recompile to change anything....
Not sure about the word, but otherwise it just perfectly fullfills its purpose:
Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.
I have really doubts whether it makes sense to package it ... shared git repository for Fedora-community maintained source code (if needed) and one tiny binary in /usr/local/bin/ should be good for everybody.
Matěj
On 10/15/2010 11:14 PM, Matej Cepl wrote:
Jesse Keating, Wed, 13 Oct 2010 17:13:43 -0700:
Am i the only one that finds it hilarious that this thing is named "Dynamic Window Manager"? So dynamic, you gotta recompile to change anything....
Not sure about the word, but otherwise it just perfectly fullfills its purpose:
Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.I have really doubts whether it makes sense to package it ... shared git repository for Fedora-community maintained source code (if needed) and one tiny binary in /usr/local/bin/ should be good for everybody.
I took the review for a few reasons: a) If Petr wants to maintain it...it's his call (as will be dealing with elitist upstream :-) ) b) Package is following packaging guidelines (apart from places where it really had to (installing sources even if it's not src.rpm for example). c) I am sure there are more useless packages in Fedora d) I like tiling WMs :-)
I really see no reason NOT to have dwm in Fedora. It's fun little WM.
On 10/13/2010 10:04 AM, Petr Sabata wrote:
I've been thinking about packaging dwm [1] since we already ship dmenu and dzen2. I wonder if anybody would be interested in this fine window manager (except for me).
The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc). In my opinion, we could do it like this:
- install a Fedora preconfigured version along with dwm sources - copy its configuration (C header file) to some fixed location for user to customize - provide a script to recompile dwm locally using the local configuration file
It doesn't make any sense at all to have a system-wide preconfigured version installed.
Surely the RPM should simply install the sources, along with a script that the user can run to copy the config files to the user's homedir and build dwm. The user would then have their own private copy of dwm.
Andrew.
Packaged, waiting for review: https://bugzilla.redhat.com/show_bug.cgi?id=643375
dwm: - installs pre-configured dwm binary dwm-users: - installs dwm sources and dwm-start tool which recompiles dwm from user's ~/.dwm/config.h, installs to ~/.dwm/dwm and runs; if there's no config or user binary, it runs the system dwm
-
Andrew Haley -
Ben Boeckel -
Jesse Keating -
Kevin Kofler -
Matej Cepl -
Matt McCutchen -
Petr Sabata -
Rudolf Kastl -
Stanislav Ochotnicky