From: Guido S. <__g...@we...> - 2005-03-28 18:06:15
Attachments:
OroboROX-0.9.6-8-ROrepatches.diff
|
28-Mar-2005 ~~~~~~~~~~~ Guido Schimmels: - don't lose focus when switching workspace by keybinding (happened with FOCUS_RISCOS only) - introduce raise_policy, seperate from focus_policy - Windows GUI sections renaming: Behaviour -> Move & Resize Focus -> Focus & Raise - change mainloop usleep(1000) -> usleep(50); doesn't affect cpu usage noticably, should make for more responsive window management. We could remove the usleep() entirely and sleep on XNextEvent() instead, if it wasn't for the raise_delay timeout. - raise delay is now actually measured in ms, as advertised, instead of counting eventloop passes like before (which meant an arbitrary time with cpu speed as the main factor) I'll release that as 0.9.7 when no serious problems are reported. Depending on your response time, it will be a late easter-egg (easter monday is a holiday in Germany), or an April Fools Joke. Attached is a patch from Bungee I didn't apply as it seems to undo some things from Jonatan's patch set. I don't know what to do about it. Please all devs involved in the horz/vert maximizing fixes have a look! |
From: Thomas L. <ta...@ec...> - 2005-03-28 19:12:25
|
On Mon, Mar 28, 2005 at 08:05:53PM +0200, Guido Schimmels wrote: > I'll release that as 0.9.7 when no serious problems are reported. Looks good. It's now up on zero install, and set as the default. To try it: - Go into /uri/0install/rox.sourceforge.net/apps/Configure/OroboROX - Click Refresh - Click on OroboROX PS: I found a few tmp files in the archive: .bzr .bzr.log .valgrind-verbose.swp OrboROX-policies.gnumeric -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Guido S. <__g...@we...> - 2005-03-28 20:59:59
|
On Mon, 28 Mar 2005 20:13:54 +0100 Thomas Leonard <ta...@ec...> wrote: > PS: I found a few tmp files in the archive: > > .bzr > .bzr.log > .valgrind-verbose.swp > OrboROX-policies.gnumeric The gnumeric file is intentional (developer documentation) The valgrind file is a vim leftover. .bzr is from bazaar-ng. A python based revision control system in early stage. Please remove those files. I experiment with bzr as I haven't settled on a revision control system. cvs is obsolete. I haven't seriously used it and now it doesn't seem time well spent learning. I found arch intriguing, but it turned out its maintainer is caught in obscure details, completely neglecting the basics. arch has no command to import a source tree (only single files), and export it again (losing the revision control files). That's why I had to write src/dist.sh. Following the arch list a while I've lost hope that's going to be fixed - cloud-coo-coo. SVN seems to win out, but to me it seems to severly suffer from 2nd-system-syndrome and sunsite.dk doesn't support it yet. The great thing about arch is, you don't need any support on the server side. Just upload it and anyone can check out who has arch installed. bazaar-ng is sponsored by the guy behind Ubuntu, that makes me hope it will be sane and followed through. |
From: Thomas L. <ta...@ec...> - 2005-03-29 09:41:22
|
On Mon, Mar 28, 2005 at 10:59:39PM +0200, Guido Schimmels wrote: [...] > I experiment with bzr as I haven't settled on a revision control > system. cvs is obsolete. I haven't seriously used it and now it > doesn't seem time well spent learning. > I found arch intriguing, but it turned out its maintainer is caught in > obscure details, completely neglecting the basics. I tried arch a while ago, but the user interface was terrible. > SVN seems to win out, but to me it seems to severly suffer from > 2nd-system-syndrome and sunsite.dk doesn't support it yet. Not sure about that. At least compared to CVS, it's quite stripped-down and simplified. I'm planning to move the ROX stuff over to it once SF roll it out. I've been using svn locally a lot. The only problems are: - Committing doesn't update your local copy of the log, so you have to remember to do 'svn update' before 'svn log'. - Doesn't do distributed stuff like arch/bzr/darcs/monotone, etc. For ROX, that's probably not a problem. Compared to CVS, svn's commands are almost identical, but everything is slightly saner and simpler, and some common operations like 'diff', 'log' and 'revert' don't need network access. darcs doesn't store the X bit, which is annoying. It seems quite different to the others, but it has a very beginner-friendly interface, and works over HTTP. Apparently it has scaling issues, though. Monotone seems interesting too. It solves the problem of conflicts by simply allowing multiple heads at once. It uses cryptographic hashes to identifiy revisions, so the heads merge automatically if you edit them sufficiently that they become identical! > The great thing about arch is, you don't need any support on the > server side. > Just upload it and anyone can check out who has arch installed. > bazaar-ng is sponsored by the guy behind Ubuntu, that makes me hope it > will be sane and followed through. So is your bazaar repository available somewhere? -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Arioch <the...@nm...> - 2005-03-29 10:21:37
|
Thomas Leonard =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Compared to CVS, svn's commands are almost identical, but everything is= > slightly saner and simpler, and some common operations like 'diff', > 'log' and 'revert' don't need network access. > darcs doesn't store the X bit, which is annoying. It seems quite > different to the others, but it has a very beginner-friendly interface,= > and works over HTTP. Apparently it has scaling issues, though. Ain't there beginner's friendly interfaces for SVN and CVS ? At least for Windows there are. http://www.tortoisecvs.org/screenshot1.png http://tortoisesvn.tigris.org/images/ExplorerView1.png |
From: Ken H. <ke...@ha...> - 2005-03-29 14:41:30
Attachments:
ken.vcf
|
Arioch wrote: > Thomas Leonard =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> Compared to CVS, svn's commands are almost identical, but everything i= s >> slightly saner and simpler, and some common operations like 'diff', >> 'log' and 'revert' don't need network access. > > >> darcs doesn't store the X bit, which is annoying. It seems quite >> different to the others, but it has a very beginner-friendly interface= , >> and works over HTTP. Apparently it has scaling issues, though. > > > Ain't there beginner's friendly interfaces for SVN and CVS ? > At least for Windows there are. > > http://www.tortoisecvs.org/screenshot1.png > http://tortoisesvn.tigris.org/images/ExplorerView1.png I'm working on ROX svn currently. I'll post some screenshots soon. I'd=20 welcome suggestions and feedback. I'm using TortoiseSVN as a model for the dialogs, but not trying to tie=20 it into Filer (unless someone suggests a good way to do that). |
From: Guido S. <__g...@we...> - 2005-03-29 12:10:05
|
On Tue, 29 Mar 2005 10:42:53 +0100 Thomas Leonard <ta...@ec...> wrote: > On Mon, Mar 28, 2005 at 10:59:39PM +0200, Guido Schimmels wrote: > [...] > > I experiment with bzr as I haven't settled on a revision control > > system. cvs is obsolete. I haven't seriously used it and now it > > doesn't seem time well spent learning. > > > I found arch intriguing, but it turned out its maintainer is caught in > > obscure details, completely neglecting the basics. > > I tried arch a while ago, but the user interface was terrible. Yes it is. The tutorial looked good first, but when I started using arch, I found it answered all those questions I never had, about problems I didn't know I wanted to solve. For the most basic things I had to read the wiki how to get something done by piping GNU tools. It wasn't my intention to write my own rcs ad hoc in bash really:( That's what I referred to as cloud-coo-coo. There are a couple of wrapper scripts in bash, perl and python which try to give it a friendlier face. But that ends up messy with the documentation and gui and IDE tool support, which do not know about Jim's and Joe's arch wrappers. And what Tom Lord really should get into his head, it doesn't matter if you provide the best collaboration tool in the world, when you run the project in a way, so potential users have nobody to collaborate with. Like make it depend on GNU coreutils, effectively making it Linux only. And flaming list subscribers... > > SVN seems to win out, but to me it seems to severly suffer from > > 2nd-system-syndrome and sunsite.dk doesn't support it yet. > > Not sure about that. At least compared to CVS, it's quite stripped-down I was more referring to the code size. It's quite huge. And early versions only had the bdb backend, which made me feel uncomfortable. > and simplified. I'm planning to move the ROX stuff over to it once SF > roll it out. Need to ask the sunsite.dk staff about it. My first experiments failed miserably. I tried to get started through eSvn, which doesn't seem to support local repositories only. It insists on a URL as well, so at this point it ended for me. Probably I shouldn't blame svn for limitations of a gui frontend, but that was my first impression. > Monotone seems interesting too. It solves the problem of conflicts by > simply allowing multiple heads at once. It uses cryptographic hashes to > identifiy revisions, so the heads merge automatically if you edit them > sufficiently that they become identical! I wanted to try some time ago, but was too much hassle to install from source. Now got the latest binary. Will have another look. > > The great thing about arch is, you don't need any support on the > > server side. > > Just upload it and anyone can check out who has arch installed. > > bazaar-ng is sponsored by the guy behind Ubuntu, that makes me hope it > > will be sane and followed through. > > So is your bazaar repository available somewhere? Sorry no. Didn't do much more than import the tree yet. Not seriously worked with it, that's why the rcs files are left in the first place, simply forgot about them. Getting OroboROX released was the priority. |
From: Guido S. <__g...@we...> - 2005-03-29 16:13:17
|
On Tue, 29 Mar 2005 10:42:53 +0100 Thomas Leonard <ta...@ec...> wrote: > Monotone seems interesting too. It solves the problem of conflicts by > simply allowing multiple heads at once. It uses cryptographic hashes to > identifiy revisions, so the heads merge automatically if you edit them > sufficiently that they become identical! Well, I went through the tutorial and imported OroboROX into a local monotone sqlite database. The documentation is very well written and monotone is looking like a straight forward implementation of a p2p collaboration model. But that would be my concern. Its seems to be geared towards workgroups on a LAN. It doesn't look like it's meant to replace cvs on the likes of Sourceforge. if I wanted to provide an equivalent for anonymous cvs, would monotone do anything for me at all? Or needed I to independently from that offer a zsync (http://zsync.moria.org.uk/) download or something like that. What I like is that monotone doesn't clutter up the working copy with its files. There is a toplevel MT/ directory with two files in it, and that seems to be it. Everything else is being stored in the sqlite database file. I also like how syncing with the group members doesn't directly affect my working copy. It all goes into the db, where I can investigate the changes and only then I may decide to transfer changes into my working copy. And I like monotone being a single file and not much in terms of library dependencies and it doesn't assume the presence of obscure coreutils commands, so it is pretty much self-contained, which never hurts. ldd says: linux-gate.so.1 => (0xffffe000) libpopt.so.0 => /usr/support/lib/libpopt.so.0 (0x498b0000) libdl.so.2 => /lib/libdl.so.2 (0x49501000) libstdc++.so.5 => /boot/develop/gnu/lib/libstdc++.so.5 (0x4000d000) libm.so.6 => /lib/libm.so.6 (0x49506000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4a0a8000) libc.so.6 => /lib/libc.so.6 (0x493e7000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x493ce000) I haven't used cvs in the past, because for my little projects, for its shortcomings, I felt it wouldn't make my life easier - rather more complicated. So when I wanted to make bigger changes, I simply tared up the tree and went along. That worked well enough and contributions from other people can easily enough be managed via diffs for such small projects with few contributors. I might change my habits if I find a rcs which doesn't get into my way and isn't more a burden than truly helpfull. The trouble is, collaboration tools strongly depend on popularity to be viable. You lose potential contributors if they have to learn your rcs of choice first. And toolchain integration is only available for the popular systems. Basically it looks like cvs/svn and to some extend the proprietary solutions only. At least monotone makes such integration easy by offering an alternative, easily parseable, command set for tool integration and is scriptable with LUA (which is only somewhat popular in the windows world and almost ignored on Linux, though). svn is really the path of least resistance. But at least as long as sunsite.dk doesn't support it I will try the alternatives. |
From: Thomas L. <ta...@ec...> - 2005-09-19 20:00:52
|
On Tue, 29 Mar 2005 18:13:03 +0200, Guido Schimmels wrote: > On Tue, 29 Mar 2005 10:42:53 +0100 > Thomas Leonard <ta...@ec...> wrote: >> Monotone seems interesting too. It solves the problem of conflicts by >> simply allowing multiple heads at once. It uses cryptographic hashes to >> identifiy revisions, so the heads merge automatically if you edit them >> sufficiently that they become identical! > > Well, I went through the tutorial and imported OroboROX into a local > monotone sqlite database. The documentation is very well written and > monotone is looking like a straight forward implementation of a p2p > collaboration model. But that would be my concern. Its seems to be geared > towards workgroups on a LAN. It doesn't look like it's meant to replace > cvs on the likes of Sourceforge. if I wanted to provide an equivalent for > anonymous cvs, would monotone do anything for me at all? With the various different copies of your stuff floating around (including my ones with newer findrox on rox.sf.net), it would be useful to have some versioning system in place. Have you looked at cogito? It's built on GIT, and the Linux developers are using it. It wasn't around when we last discussed SCMs, but it looks quite nice. And simple: $ mkdir myprogram $ cd myprogram $ cg-init $ ls -A .git [ create some files ] $ cg-add file1 file2 $ cg-commit To make the repository available, make the myprogram/.git directory available on a web server. Other people get it with: $ cg-clone http://site/myprogram.git myprogram They can make their version available in the same way, and you can pull from it: $ cg-add-branch thomas http://othersite/thomas.git $ cg-update thomas etc. I've only had a brief play, but it looks good so far. Anyone else have experience with it? -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Tony H. <h...@re...> - 2005-09-19 20:32:44
|
In <pan...@ec...>, Thomas Leonard wrote: > With the various different copies of your stuff floating around (including > my ones with newer findrox on rox.sf.net), it would be useful to have some > versioning system in place. > > Have you looked at cogito? It's built on GIT, and the Linux developers are > using it. It wasn't around when we last discussed SCMs, but it looks quite > nice. And simple: How about subversion (svn)? I know there are features in some of the other tools that a lot of people prefer, but svn is definitely a big improvement on cvs and has a lot more support than any of the other alternatives. Sourceforge are assessing it, but God knows when, or even if, they'll implement it. Berlios already implements it. I think I might use Berlios for my new projects instead of Sourceforge, because of svn, and the web server generally seems a lot more responsive too. -- TH * http://www.realh.co.uk |
From: Jonatan L. <th...@ho...> - 2005-03-28 23:07:48
|
On Mon, 28 Mar 2005 20:05:53 +0200 Guido Schimmels <__g...@we...> wrote: > > 28-Mar-2005 > ~~~~~~~~~~~ > > Guido Schimmels: > - don't lose focus when switching workspace by keybinding (happened > with FOCUS_RISCOS only)- introduce raise_policy, seperate from > focus_policy- Windows GUI sections renaming: > Behaviour -> Move & Resize > Focus -> Focus & Raise * The "Move pointer after cycle" option is gone from the GUI. * So are the "auto switch workspace" option. * It's not possible to turn off auto raise in "unix raise policy" since raise delay minimum is now 0 instead of -1... ...What should be the difference between unix and riscos raise policy if auto raise is off? The thing is that there IS different behaviour and that's why I want unix policy but without autoraising: in riscos raise policy it no longer works to hold winops-modifier and click anywhere in a window to raise it. This is probably a bug, since clicking (left/middle/right/wheel) in a window while holding winops-modifier ALLWAYS should behave exactly as if you did the same thing on the frame/titlebar. And since riscos mode does raise a window when clicking on the frame, it should do so also here. try_raise_on_click() does a check that window_type is not win-content, but it shouldn't check this if win_ops was used... damn, handleButtonPress() should _really_ be cleaned up. It's a huge mess with all those if's and goto's... That table you did should be helpfull to rewrite this function. /Jonatan -=( http://kymatica.com )=- |
From: Jonatan L. <th...@ho...> - 2005-03-29 00:00:42
|
On Tue, 29 Mar 2005 01:11:19 -0300 Jonatan Liljedahl <th...@ho...> wrote: > damn, handleButtonPress() should _really_ be cleaned up. It's a huge > mess with all those if's and goto's... > That table you did should be helpfull to rewrite this function. Here's a proposal in pseudo code: handleButtonPress() { if win_ops || area was frame { case button { left: if RAISE_WIN || RAISE_RISCOS: raise = true if FOCUS_WIN: focus = true if area was border: do_border_drag() middle: do_middle_action(&raise,&lower,&focus) right: do_right_action(&raise,&lower,&focus) wheel: do_wheel_action(&raise,&lower,&focus) } } else { //content if FOCUS_WIN || FOCUS_RISCOS: focus = true if RAISE_WIN: raise = true } if raise: raiseClient() else if lower: lowerClient() if focus: focusClient() } do_*_action() functions checks the button[23]_frame_{drag,click} options and does the right things, i'm not sure if it would be nessecary to pass references to raise, lower and focus variables as shown above, but you get the idea. unix style auto-focus and auto-raise is handled as it should already in handleEnterNotify()... What do you think? /Jonatan -=( http://kymatica.com )=- /Jonatan -=( http://kymatica.com )=- |
From: Jonatan L. <th...@ho...> - 2005-03-29 01:23:07
|
On Tue, 29 Mar 2005 02:04:49 -0300 Jonatan Liljedahl <th...@ho...> wrote: > On Tue, 29 Mar 2005 01:11:19 -0300 > Jonatan Liljedahl <th...@ho...> wrote: > > > damn, handleButtonPress() should _really_ be cleaned up. It's a > > huge > > mess with all those if's and goto's... > > That table you did should be helpfull to rewrite this function. > > Here's a proposal in pseudo code: [snip] Ok, I've almost done with the rewrite of handleButtonPress() now... =) I'll send a patch tomorrow evening... /Jonatan -=( http://kymatica.com )=- |
From: Jonatan L. <th...@ho...> - 2005-03-29 23:11:39
Attachments:
0.9.6-9.lijon1.patch.gz
|
On Tue, 29 Mar 2005 03:27:12 -0300 Jonatan Liljedahl <th...@ho...> wrote: > On Tue, 29 Mar 2005 02:04:49 -0300 > Jonatan Liljedahl <th...@ho...> wrote: > > > On Tue, 29 Mar 2005 01:11:19 -0300 > > Jonatan Liljedahl <th...@ho...> wrote: > > > > > damn, handleButtonPress() should _really_ be cleaned up. It's a > > > huge > > > mess with all those if's and goto's... > > > That table you did should be helpfull to rewrite this function. > > > > > > > Here's a proposal in pseudo code: > [snip] > > Ok, I've almost done with the rewrite of handleButtonPress() now... > =) I'll send a patch tomorrow evening... Here it is! The attached 0.9.6-9.lijon1.patch.gz contains the following changes: 29-Mar-2005 ~~~~~~~~~~~ Jonatan Liljedahl: * Rewrote handleButtonPress(), it's a lot cleaner now. Hopefully everyone is happy with the focus/raise behaviours. * Put back "Warp after cycle" and "Auto switch workspace" options to Window options GUI, under the "Advanced" section and moved "Window matching" to a separate section. * Started to update the user manual, using AFT with custom stylesheet similar to ROX-Filers manual. The source is in src/doc/Manual.aft /Jonatan -=( http://kymatica.com )=- |
From: Thomas L. <ta...@ec...> - 2005-09-21 14:17:17
|
On Mon, 19 Sep 2005 21:32:38 +0100, Tony Houghton wrote: > In <pan...@ec...>, Thomas Leonard wrote: > >> With the various different copies of your stuff floating around (including >> my ones with newer findrox on rox.sf.net), it would be useful to have some >> versioning system in place. >> >> Have you looked at cogito? It's built on GIT, and the Linux developers are >> using it. It wasn't around when we last discussed SCMs, but it looks quite >> nice. And simple: > > How about subversion (svn)? That was my suggestion too, but Guido wanted something that would work on sunsite. Here's the rest of the thread: http://thread.gmane.org/gmane.comp.desktop.rox.devel/6833 -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Guido S. <__g...@we...> - 2005-09-21 18:24:29
|
On Wed, 21 Sep 2005 15:07:52 +0100 Thomas Leonard <ta...@ec...> wrote: > On Mon, 19 Sep 2005 21:32:38 +0100, Tony Houghton wrote: > > > In <pan...@ec...>, Thomas Leonard wrote: > > > >> With the various different copies of your stuff floating around (including > >> my ones with newer findrox on rox.sf.net), it would be useful to have some > >> versioning system in place. > >> > >> Have you looked at cogito? It's built on GIT, and the Linux developers are > >> using it. It wasn't around when we last discussed SCMs, but it looks quite > >> nice. And simple: > > > > How about subversion (svn)? > > That was my suggestion too, but Guido wanted something that would work on > sunsite. Here's the rest of the thread: That's why I rejected monotone finally. You really need a server of your own for it. No use for a hosted site like sunsite, berlios, sourceforge... I played a little with darcs, which is also very simple, like cogito sounds it was. It's probably never going to be wildy popular, but nothing except svn will, I'm afraid. The only downside is scaleability, supposedly. It's said get slow rapidly with project size. But my personal projects, as well as ROX related projects in general are quite small, usually. |