Closed 01micko closed 8 years ago
Do you suggest to eliminate pup_event or just the drive management option? There are several pup_event functions needed in other programs, so it needs to be looked at carefully if so. Regarding maintaining pup_event_frontend_d.bac, as long as BK builds quirkies we are safe :stuck_out_tongue_winking_eye:
The whole thing needs to be addressed. It's a case of either we use udev or pupevent. It's that simple. Otherwise the 'xorg' branch is a waste of time, because udev/eudev is critical to that scenario, and conflicts with legacy pupevent.
Can you be a bit more specific? Udev is in puppies for years now in parallel with pup_even. How pup_event affects udev function? Not that I have any attachment to pup_even. I'm mostly curious (and try to save work that will be needed in other scripts)
#110823 mavrothal: Check if it is an OLPC XO and add the devices...
#also need for no xorg.conf
#ISITANXO=`cat /sys/class/dmi/id/product_name`
if [ $UDEVVER -gt 150 ] ; then
udevadm trigger --action=add --subsystem-match="input" --subsystem-match="sound"
udevadm settle
fi
(from 'xorg' branch /etc/rc.d/rc.sysinit)
This is but the tip of the iceberg.
Hard to say for sure, but part of the reason firmware isn't found for ipw network devices could be the legacy location of the firmware.
IMO, bettor off to go all or nothing. If nothing, I'll delete the 'xorg' branch and someone else can figure it out.
Udev is everywhere in rc.sysinit
#my intention is for puppy to work with either of these...
if [ -f /sbin/udevd ];then
If you make rc.sysinit more verbal you can see udev re-running all the kernel events (that is one of the slowest steps during boot) It may need to be configured better though.
Regarding firmware, we also have a firmware branch 2 years now :wink: . It still need pup_even for old modems to do the moving but other than that should be fine. We also have some firmware pets configured accordingly (with 'CE' in their name). We may want to revisit and see if we can merge with xorg branch. There are just few changes
pup-volume-monitor is the kind of apps that could have made puppy the leading live distro back in the day...
Adding out-of-the-box support for pup-volume-monitor is really the best thing that can happen to puppy... I once had pcmanfm and roxfiler working the way they should with no problems.
Puppies are now heavy anyways, so I think the first step is to add proper support for pup-volume-monitor, that way volumes will appear everywhere... but in ROX.
Talking about LXpup, most LXDE apps are generic and tiny: lxterminal lxtask lxrandr lxinput gpicview [*]
These all work fine in any puppy anytime, they should be added to all woofce puppies and made default, just compile them in Wary and they will work in Precise Tahrpup Slacko, etc...
I do not think there is any argument against pup-vorume-monitor. My Precise installation has it! The argument is if pup_even should be eliminated altogether and how in this case to accommodate the many scripts that utilise it.
There are parts of the eventmanager that should be removed. In /etc/eventmanager there are switches to turn off unwanted functionality
Then we are faced with the biggest problem in puppy: ROX, that's why the drives are shown in the desktop, because ROX is old and outdated, with a bad design. Maybe it was meant for mobile devices back in 2005.
Drive icons in the desktop are not essential, so using traditional file managers with pvm could be the solution.
As far as I know, PVM has a config file, so it can be costumized and functionality can be added for mounting/unmounting. So I think ROX is not need, I mean the file manager... the whole thing I guess.
Then we are faced with the biggest problem in puppy: ROX
Haha, slow down here. ROX is a sacred subject. Seriously - some people swear off Rox (as you obviously do), some swears by Rox. Can you please tell me and the rest of us why Rox is a problem? And why is it the biggest problem? Seriously? It's not that you couldn't install another file manager if you don't like it.
that's why the drives are shown in the desktop
That is definitely not why drives are shown on the desktop. The decision to show drives on the desktop was done because people thought it was user-friendly. It had nothing to do with Rox.
because ROX is old and outdated, with a bad design. Maybe it was meant for mobile devices back in 2005.
Careful here. You're making a lot of baseless statements. Rox is old, yes. But what makes you think it is outdated? What do you think of a "modern" (not outdated) design? Why do you think its design is bad? What do you think is good design? Do you know the state of mobile devices back in 2005? Please explain.
Drive icons in the desktop are not essential,
Says you. Others may have a different opinion.
so using traditional file managers with pvm could be the solution.
PVM is a good replacement for pupevent* stuff. "Traditional" file managers are okay too. But it doesn't mean you have to throw Rox out of it. If you do want to throw out Rox, then exactly what "traditional" file manager you're thinking of as a replacement? pcmanfm? spacefm? thunar? nautilus? xfe? PathFinder? emelfm? etc?
So I think ROX is not need, I mean the file manager... the whole thing I guess.
Like I say, some people swears off Rox, and some swears by Rox. If you want to remove Puppy dependency from Rox, you're more than welcome. It's never good to depend on a project that is no longer updated.
But, if you want to rid Puppy of Rox completely - I guess you'd better consider that or at the very least, open a poll on the forum to gauge the response. There is a reason "jwm" is still the default file manager despite of its perceived (and real) problems. Same goes with Rox.
Anyway, this issue is about getting rid of pupevent* stuff. Discussion about Rox is tangential but not essential. You have a completely pupevent*-free system that still uses Rox. And vice versa.
I love Rox, but it would still be a good thing if Rox wasn't hardcoded in Woof. I believe the work to remove Rox from Puppy is incredible complex, so I think a new branch is required to make this giant step.
I love Rox, but there is one major lack of feature that irritates me every day. It doesn't (like the gtk open/save box) autoscroll to files when I press a key. Ie. when I press the S-key in the Gtk open dialog, it scrolls to files that begin with S... I know there exists some pathes, Are the collected/implemented? Who have done those pathes?
Sorry for getting off-topic...
Well, there are lot of rox -D
pcmanfm automatically closes its window or TAB when a directory is deleted, that is the correct behavior..
really? when I've done it I get a little popup window and when I click Ok it closes the rox window for the deleted folder. Example: http://i.imgur.com/n6EhFBb.png
On Thu, Dec 17, 2015 at 7:07 PM, wdlkmpx notifications@github.com wrote:
Well, there are lot of rox -D , which is a command to close a rox window. I noticed that if you delete a directory and rox has that directory open, it will complain and complain until you kill it somehow. That is an annoying bug..
pcmanfm automatically closes its window or TAB when a directory is deleted, that is the correct behavior..
— Reply to this email directly or view it on GitHub https://github.com/puppylinux-woof-CE/woof-CE/issues/671#issuecomment-165620655 .
closing this as I don't have time to maintain PVM
I have forked @akashrawal 's pup-volume-monitor and desktop-drive-icons from google-code.
@peabee has been using this successfully in LXpup for quite a while now. I know akash has gone quiet for some time but the code looks to me well written and quite maintainable with the resources that we have. Does anyone really want to maintain
pup_event_frontend_d.bac
written in BaCon?I suggest that PVM could be used as default in woof based puppies especially since udev/eudev seems more critical now than ever in discovering devices. optionally, a builder could fall back to pup_event if they were building for a restricted platform, such as raspberry pi.
Anyone have any thoughts on this?