Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 20 Jun 2018, 19:14
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Gtkwialog project (abandoned)
Post new topic   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
Page 6 of 7 [95 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Author Message
wiak

Joined: 11 Dec 2007
Posts: 857
Location: not Bulgaria

PostPosted: Wed 06 Jun 2018, 21:32    Post subject:  

@aaaaa: the code is still being tested to see if useful and likely to be adopted. There seems to be a certain amount of resistance to the work, which does not surprise me, or should I say some lack of 'interest'. The repo development is a work in progress and is pending on official release status.

If the work proves to be a headache for some in the Dog or Puppy community it may truly not be worth the effort in terms of having to put up with the negative reactions. I am unlikely to participate in an atmosphere of any misinformation and negativity and won't invite or encourage that situation whether a few are interested in the project or not - it has been a lot of effort to simply be sucked up by a team who have contributed nothing in terms of testing or enthusiasm. But I am happy with it for my own purposes, which is to run my DebianDog-based systems with dash as shell, rather than the ugly bash hack that is due to gtkdialog apps mainly.

After years of too much negativity from some quarters on here, I am finding myself in much less of a community spirit, frankly, despite there being some old Dog-developer connections and a few other exceptions to that comment.

But yes, your getenv preference would be a nice additional option so that one could chose the preferred method to activate the new modes - easily done and I'll bear that in mind.

The following by the way is pretty much the simple method being used to select the new modes anyway, albeit for commandline args rather than a getenv result:

aaaaa wrote:

Code:

#include <stdlib.h>

if (getenv("GTKWIALOG")) {
 GTKWIALOG=1;
}




Just two simple flags (option_blocking or option_nonblocking) used by an if statement to control the flow logic. Pretty much impossible to get wrong - safe as pie, but some insist (in negative intention apparently) on 'intensive' testing: of an if statement, as it turns out...

wiak
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 857
Location: not Bulgaria

PostPosted: Wed 06 Jun 2018, 23:50    Post subject:  

I now note that Thunor knew about the bash issue with gtkdialog running /bin/sh -c via system() call:

http://murga-linux.com/puppy/viewtopic.php?p=668694#668694

He correctly stated that one way round was to not use bashisms (but that is restrictive since bash was specially designed as a more powerful interactive and programmer's shell; a 'better' more sophisticated programming language effectively - shame to have to ignore it when programming shell apps, whilst forcing bash, in Puppy and the Dogs, as an inefficient, slow, system shell - but bash certainly fast enough at human level for simple app/util writing).

However, Thunor got it wrong thinking/suggesting in his linked post above that another solution was to use bash -c before actions in gtkdialog - his suggestion simply doesn't work for legacy gtkdialog because, as I explained, the forced /bin/sh -c invocation strips the bash environment and the bash exported function calls are lost.

Hence my gtkwialog creation/fork, which does behave the way Thunor imagined legacy gtkdialog would but didn't. Also gtkwialog removes the need to use /bin/sh stage altogether where applicable, which makes it more efficient overall.

However, let the gtkdialog faithful continue to use the crippled older legacy gtkdialog mode if so be it. Some of the 'faithful' Puppy users on here refuse to touch a Dog either - narrow mindset really helps Puppy develop. We all should be using VHS or maybe Betamax nowadays instead of all this new-fangled stuff. LOL And bash should never have been invented - what's wrong with less capable Bourne shell, they can re-write their code in that as a time-consuming 'fix'; come to that, what's wrong with re-writing all our programs in assembler (now that would likely be significantly more resource-usage efficient if somewhat clumsy and ugly comparatively to a more capable higher level language).

Bring on Lua I say - it was there in the early Pup days and goodness knows why it was dropped. Tcl/Tk not too bad to be honest either - just the widget set not exactly gtk looking (IUP with Lua does not have that limitation). But then the shell/gtkdialog coding 'experts' would have to learn something 'new' (from just 20 years or so ago) too. As for dropping multi-user capabilitity along with ugly hack of forcing bash onto the user for a system shell (which it certainly isn't designed for - system shells need speed/efficiency for obvious reasons).

Let's leave it at that, but I'll be modifying my own system and programs to remove the lack of compatibility bash-system only programs have - alas a /bin/sh in inefficient bash system tends to encourage sloppy system level script coding too in terms of introducing bashisms where they have no place (and putting #!/bin/sh as the shebang is certainly misleading when script relies on underneath system shell bash). Bash is great when used appropriately as a programmers language shell, but rubbish to use it as a forced system shell thanks to legacy gtkdialog. Gtkwialog removes that /bin/sh -> bash need and thank goodness for that, at last. (Imagine 'having' to write your shell/gtkdialog scripts in Bourne shell, Posix format syntax, to make them portable, when the underlying system is even using bash! A ridiculous state of affairs in that case!)

wiak
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 1074

PostPosted: Thu 07 Jun 2018, 00:24    Post subject:  

wiak wrote:
However, let the gtkdialog faithful continue to use the crippled older legacy gtkdialog mode if so be it.


You say it's faster, so if all the core puppy apps get ported to Gtkwialog, there is a high probability that it will get adopted by most or all puppies, provided that Gtkwialog continues to get maintained.

Clearly it will be the Debian based puppies that will adopt it first. I will note though that if we have to port programs to gtkwialog then it isn't really 100% compatible, and so therefore some may still want to use the old "crippled" version. Or maybe you don't mean port; maybe you mean optimize and forgive me if I missed something in this thread as I can't read everything in the world. Also note that I'm not a developer of a puppy distribution so it isn't up to me whether or not it gets adopted.

Anyway, I appreciate the work of all developers but the great thing about open source is that people can chose to use what they want even if their choice isn't the most optimal based on some criteria...so maybe gtkwialog is the greatest thing since sliced bread but but everyone won't discover whether or not it is so great overnight.
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1536
Location: Japan

PostPosted: Thu 07 Jun 2018, 02:17    Post subject:  

wiak wrote:
Thunor got it wrong thinking/suggesting in his linked post above that another solution was to use bash -c before actions in gtkdialog - his suggestion simply doesn't work for legacy gtkdialog

Somehow Thunor's suggestion seems to work for me.
Tested with legacy gtkdialog, /bin/sh linked to /bin/ash.
Code:
#!/bin/bash
func_bash() {
   SYSHELL=$(realpath /bin/sh)
   gxmessage $(cat <(echo "/bin/sh points to $SYSHELL"))
}; export -f func_bash

echo '<button label="Call exported function">
<action>bash -c func_bash</action>
</button>' | gtkdialog -s
Don't know if dash would behave differently from busybox ash.
"bash -c" is also be required when running above script in a standard sh/bash environment.
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 857
Location: not Bulgaria

PostPosted: Thu 07 Jun 2018, 02:28    Post subject:  

s243a wrote:
I will note though that if we have to port programs to gtkwialog then it isn't really 100% compatible, and so therefore some may still want to use the old "crippled" version. Or maybe you don't mean port; maybe you mean optimize and forgive me if I missed something in this thread


gtkwialog (without specifying the new commandline switches) is 100% compatible with legacy gtkdialog and I couldn't care less if it is adopted aside from the fact that it was offered. I document it here mainly for my own notes and stated from the very first that this would be my fork for my own use unless it was clearly wanted by Puppy community; the remarks by some of the more prominent amongst them suggesting that it is more than a pain than a pleasure, so relax.

wiak
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 857
Location: not Bulgaria

PostPosted: Thu 07 Jun 2018, 02:30    Post subject:  

MochiMoppel wrote:
wiak wrote:
Thunor got it wrong thinking/suggesting in his linked post above that another solution was to use bash -c before actions in gtkdialog - his suggestion simply doesn't work for legacy gtkdialog

Somehow Thunor's suggestion seems to work for me.
Tested with legacy gtkdialog, /bin/sh linked to /bin/ash.
Code:
#!/bin/bash
func_bash() {
   SYSHELL=$(realpath /bin/sh)
   gxmessage $(cat <(echo "/bin/sh points to $SYSHELL"))
}; export -f func_bash

echo '<button label="Call exported function">
<action>bash -c func_bash</action>
</button>' | gtkdialog -s
Don't know if dash would behave differently from busybox ash.
"bash -c" is also be required when running above script in a standard sh/bash environment.


Well good for you, use busybox ash then (don't think it worked so well when tried on mistfire's TazPup but maybe those testing it didn't test it as well as you. Interesting though, and I presume you have checked that your /bin/ash is indeed a link to busybox ash and not to bash (maybe others could confirm with their busybox ash?). It doesn't work on dash but you don't need it so that's fine. You've made your point again, and thanks. Actually, maybe it does - can't test at the moment since on wrong machine.

But if others don't have success when now trying their busybox ash, maybe you would be kind enough to post a link to your version so they can try that?

It may be that you are piping into gtkdialog from bash script so function visible at that time (I haven't thought about it as yet). Show a similar example with typical gtkdialog reading from environment variables, which is main problem we are trying to solve really and I will abandon gtkwialog as unneeded.

wiak
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 857
Location: not Bulgaria

PostPosted: Thu 07 Jun 2018, 03:08    Post subject:  

Okay, now booted other machine and downloaded busybox from Xenial repos and made /bin/sh link to busybox. Your program does work with that. Good for you and I'm sure you will test it works with other modes of legacy gtkdialog operation (e.g. -p reading dialog from exported variable) - may well do.

I'll just abandon gtkwialog then since not needed and the negatives about it becoming like badgering and a bit of a pain I don't need thanks. But yes, good for you MochiMoppel, you've been trying to push against this development from the start and perseverance has rewarded you. Bravo! Do you happen to go Badger Baiting in your spare time?

Time for me to relax for a long while and enjoy my family, and leave you all to your precious selfs.

Anyone who was experimenting with gtkwialog prealpha test binaries, please delete them; MochiMoppel and rcrsn51 have actively demonstrated that gtkdialog is preferred for future needs and gtkwialog will not be developed at least for official public release beyond that test binary stage. Thanks to those who provided positive test reports which were very informative and interesting to me. Sorry for the time you expended but hope you gained something from the experience, as I did.

wiak

Last edited by wiak on Thu 07 Jun 2018, 03:25; edited 1 time in total
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 1074

PostPosted: Thu 07 Jun 2018, 03:22    Post subject:  

wiak wrote:
Okay, now booted other machine and downloaded busybox from Xenial repos and made /bin/sh link to busybox. Your program does work with that. Good for you and I'm sure you will test it works with other modes of legacy gtkdialog operation (e.g. -p reading dialog from exported variable) - may well do.

I'll just abandon gtkwialog then since not needed and the negatives about it becoming like badgering and a bit of a pain I don't need thanks. But yes, good for you MochiMoppel, you've been trying to push against this development from the start and perseverance has rewarded you. Bravo! Do you happen to go Badger Baiting in your spare time?

Time for me to relax for a long while and enjoy my family, and leave you all to your precious selfs.

wiak


Don't get discouraged. If you believe in it then keep at it but if you think there are better uses of your time then it is your time to do with as you please.

Whether or not you stick with it, please keep gtkwialog in the title so that others can find this thread easier in case they decide to continue your work.

best wishes. I hope that all is well.
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 857
Location: not Bulgaria

PostPosted: Thu 07 Jun 2018, 03:29    Post subject:  

Like I said, the project was demeaned as not useful and is now abandoned in its entirety. There is no longer any gtkwialog and no reason for retaining any such title by me. I did what I thought was right and best but thanks first to rcrsn51 and finally to MochiMoppel who made it perfectly clear they did not appreciate my 'tinkering' with legacy gtkdialog, which they insist is fine, I no longer need to think about this further or continue on to its publication. The Puppy Steward's had no interest either - I get the message thanks. Time I took a back seat. Been a long time coming.
Last edited by wiak on Thu 07 Jun 2018, 03:32; edited 2 times in total
Back to top
View user's profile Send private message 
darry19662018

Joined: 31 Mar 2018
Posts: 184

PostPosted: Thu 07 Jun 2018, 03:30    Post subject:  

Damn Gtkwialog had real promise.
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 1074

PostPosted: Thu 07 Jun 2018, 03:33    Post subject:  

wiak wrote:
Like I said, the project was demeaned as not useful and is now abandoned in its entirety. There is no longer any gtkwialog and no reason for retaining any such title by me. I did what I thought was right and best but thanks first to rcrsn51 and finally to MochiMoppel who made it perfectly clear they did not appreciate my 'tinkering' with legacy gtkdialog, which they insist is fine, I no longer need to think about this further or continue on to its publication. The Puppy Steward's had no interest either - I get the message thanks.


Why is it up to them whether or not you tinker with it, and I hope you abandoned it because of your opinion of the project and not any perceived flack.
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 1074

PostPosted: Thu 07 Jun 2018, 03:34    Post subject:  

darry19662018 wrote:
Damn Gtkwialog had real promise.


It sounded interesting to me but unfortunately I don't know enough about either it or GTKdialog.
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 857
Location: not Bulgaria

PostPosted: Thu 07 Jun 2018, 03:41    Post subject:  

s243a wrote:

Why is it up to them whether or not you tinker with it.


No, I accept that MochiMoppel says he can do the same without gtkwialog if he says so. rcrsn51 has a number of apps that are becoming relatively core on DebianDogs and he has stated categorically that he also has no interest in the gtkwialog project. Fred can use MochiMoppel's solution - though he will have to ask Mochi... for the implementations details since I barely looked at it. The decision to abandon was mine - the past few days have been somewhat disappointing and discouraging, so abandoning became more and more likely as the best solution for me personally - particularly when rcrsn51 went to the trouble or re-writing one of his simpler apps so it would work on dash systems with gtkdialog rather than accepting the converted gtkwialog version I sent him (admittedly I had been unable to test that so might have needed a few simple tweeks). Anyway these guys are too serious, and worse, for me and I don't like this negative nit-picking anti-development atmosphere. My choice to abandon entirely.

But thanks for your concern. Use what MochiMoppel gives you instead.

wiak (alias mcewanw)

Last edited by wiak on Thu 07 Jun 2018, 04:35; edited 1 time in total
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 3198

PostPosted: Thu 07 Jun 2018, 03:59    Post subject:  

I don't only suspect that there will be some leading old and well-established members of the Puppy Linux Team who will be breathing a sigh of relief. Their taken ownership of gtkdialog is not something they would like to see being ever taken over by an improved fork by the DebianDog Organization (which I used to help administer), despite the Pups sometimes pretending to share kennels. Let's be honest about that.

There has, however, never been negative feelings expressed from the Dog community to Puppy itself, as far as I understand it - most of us have always used Puppy to a greater or now lesser extent. Makepup (along with early cast2chrome dotpet release) was my own final attempt to show my support for Puppy despite the fact I had been primarily developing for and on DebianDog systems since 2013 (including the tiny C code chpupsocket DebDog system file). Makepup (and its sibling Makeblog) took a fair amount of effort, though I certainly admit that as a frontend-to-woof-CE pup building program it does unfortunately have great limitations.

I am maybe breathing a sigh of relief too - I was getting very tired with all of the negativity this work was bringing on me. I was programming in pain with broken ribs and punctured lung, which made the work especially hard and concentration difficult, through most of it so the extra kicks in the gut were not entirely appreciated.

Actually, I had already left this forum but unfortunately that alter-ego of mine, wiak, suddenly started developing some new stuff like tomorrow would never come. So I had to ask to have my old password re-activated so I could upload some new versions of old apps, such as Precord, to their appropriate threads.

It's all a comedy anyway; let's laugh.

mcewanw (the other wiak)

Last edited by mcewanw on Thu 07 Jun 2018, 07:22; edited 2 times in total
Back to top
View user's profile Send private message Visit poster's website 
nosystemdthanks

Joined: 03 May 2018
Posts: 168

PostPosted: Thu 07 Jun 2018, 05:20    Post subject:  

i dont know how much of it is misunderstanding and how much of it is intended to be discouraging.

this is the most pro-remix community i know, but sometimes you stumble into a sacred cow and people start getting out torches and pitchforks.

it should be more like the webcomic freefall-- after every angry chase there is ice cream for those who participated. but people do get discouraged.

i have mixed feelings about gtkdialog, the original:

* just about the coolest thing ever

* a complete mess

i believe fig os (older versions) had gtkdialog because petget called it, and it imported everything it needed for petget to load packages.

other than that: what s243a said. which makes me wonder what word starts with s and is 245 letters long. i can tell you its not in the oed.
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 6 of 7 [95 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Post new topic   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0809s ][ Queries: 14 (0.0122s) ][ GZIP on ]