Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow free(NULL); " patch...

2020-05-17 Thread Jörg F . Wittenberger

On May 17 2020, sur-behoffski wrote:


and are in strict conformance with C's definition of how free(3) is
mandated to work when its parameter is NULL (codified in C89 standard,
and included in all C and C++ standards since).


IMHO it's still better to NOT call free(3) if there is no memory to be 
released. Let alone changing good code in order to rely on free accepting a 
NULL pointer too.




___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] Request

2019-12-07 Thread Jörg F. Wittenberger
Hi Andrew,

On Sun, 1 Dec 2019 17:09:57 -0700
"Andrew Robinson"  wrote:

> Antonio,
> 
> If you don't feel like having this discussion, let me know and I can
> save it for another time...

Frankly, I don't want to really enter into this discussion.

Just I strongly disagree.

> [...]
> work, otherwise someone would have done it already. If I were to pick
> sides (and I have had to pick sides) I would choose native Windows
> and hobble UTF-16 in Linux because Linux represents less than 3% of
> the entire market that IUP could ever appeal to. Without good
> internationalization support, only Westerners will want to use IUP.
> You know this because you've seen the complaints about this already,
> and it will only get worse.

IUp's unique selling point never was to be yet another low code
tool to create applications for Windows.  There are enough out there.

Its USP was portability.

I'd rather look into supporting Android and iOS via IUp.  This kills
those 3%.  Others research pointet out that UTF-8 is usually the
better thing internally.  IUp wraps Windows with a compatibility layer
anyway, doesn't it?  Why should leak low level encoding information to
the application layer?

Best Regards

Jörg


___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

2018-04-19 Thread Jörg F . Wittenberger

Eric,

I'm afraid your comment bdelow does not make much sense to me. Also I did 
not suggest any polling.


On Apr 19 2018, Eric Wing wrote:


On 4/19/18, Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> wrote:

On Apr 19 2018, Eric Wing wrote:


Since there seems to be so much concern and speculation about the
size, complexity, and implementation of what the patch might look
like, I went ahead and implemented a fully working version for Windows
and GTK to provide something completely concrete to review.


I'm afraid there was little concern or speculation about size and 
complexity. The only concerns I read where calling into question whether 
or


not it was a good idea at all. Thus suggestions flowing your way how 
others


would solve or have solved the issue.



That is fair, up to a point. There was lengthy discussion on
PostMessage vs. PostThreadMessage and the consequences of such.


To respond to your previous post/solution...(the IupFlush
clarification), your solution actually could work. I could create an
IupTimer and externally poll. But this has a major downside in battery
consumption...and the higher the responsiveness, the worst the
consumption.

Modern native event loops are highly optimized to not do work when
nothing needs to be done. (Set a breakpoint after Windows GetMessage,
and it is fascinating how often it just sits there not moving.)
Polling though an external mechanism means burning cycles even when
not needed, which also means modern CPUs which have automatic
throttling can't usually do so in this scenario. This is why all the
platforms designed their own event-loops and intertwined their GUI
infrastructure with it, and why IUP had to abstract the native event
loops in the first place.

For the use cases I need, this unfortunately is not an acceptable
trade-off. And I think in general, there is no good reason to have to
make this trade-off. A cross-platform yet native solution is only a
handful lines of code because the native platforms intended to solve
this very problem already and expected you to use it. For the cases
where polling and burning CPU is acceptable, those are typically
games. There we are used to having non-native event loops... SDL is an
example of providing such a loop. But even SDL has the capability of
posting custom messages to its event queue to deal with these exact
same kinds of threading issues.


Thank you for the suggestion though. I understand you were sincerely
trying to solve my problem.

Thanks,
Eric

 
-- 
Check out the vibrant tech community on one of the world's most engaging 
tech sites, Slashdot.org! http://sdm.link/slashdot 
___ Iup-users mailing list 
Iup-users@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/iup-users



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

2018-04-19 Thread Jörg F . Wittenberger

On Apr 19 2018, Eric Wing wrote:


Since there seems to be so much concern and speculation about the
size, complexity, and implementation of what the patch might look
like, I went ahead and implemented a fully working version for Windows
and GTK to provide something completely concrete to review.


I'm afraid there was little concern or speculation about size and 
complexity. The only concerns I read where calling into question whether or 
not it was a good idea at all. Thus suggestions flowing your way how others 
would solve or have solved the issue.


Best

/Jörg

...

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

2018-04-19 Thread Jörg F . Wittenberger

On Apr 18 2018, Matt Welland wrote:


On Wed, Apr 18, 2018 at 1:23 AM, Jörg F. Wittenberger <
joerg.wittenber...@softeyes.net> wrote:


Hi,

just my two cents.

On Apr 16 2018, Eric Wing wrote:

This is a proposal to introduce a way to post and run events on the

main UI thread.

Currently (as far as I know), IUP is hands-off on threads.



...

It's easy to see the problem you're facing.

I'm no IUP expert, however I'm pretty positive that this can be solved
without introducing another API.

In a similar situation I have been able to abstain from using the 
complete IUP abstraction around the main loop and resort to using 
IupFlush() instead. Doing so allows to queue requests from other threads 
for execution in the GUI thread, which processes said queue right before 
calling IupFlush().


Once I had these roughly 40 lines of code in place begin factoring out
IupFlush()s and run them just once before IupFlush() to reduce some
flickering.

Maybe such an approach can work for you too.



Hi Jörg, this approach sounds really interesting. Can you provide a little
more detail to clarify how this works? Do you put calls to set attribute in
the queue and then periodically execute the calls in the queue followed by
an IupFlush? I tried this (using the Chicken Scheme IUP binding) and it
seems to work well but I'm concerned there are corner cases to be accounted
for. My (probably naive) test implementation of your approach is pasted
below.


Hi Matt,

Exactly that's what I did. (Slightly more elaborate than your example code, 
e.g. using a configurable sleep time and not using thread-sleep! but 
waiting with timeout on a condition-variable, which has the added advantage 
that urgent signals can easily terminate the wait by signaling the 
condition variable, while non-critical changes may be postponed until the 
regular update takes place.)


But the principle is the same.

Yes, you are right, there can be corner cases. You really, really want to 
be sure that your Iup callbacks don't capture continuations. But it is a 
while ago that this was fixed right in the iup egg. From your code I'm 
afraid another such corner case would be whether or not you empty the queue 
one-by-one (as I would suggest) or all at once. Your case of doing the 
latter but flushing the queue only _after_ processing it looks a bit error 
prone to me.


BEst

/Jörg






Best

/Jörg






--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users



;; trial of replacing iup:main-loop with a queue
(use (prefix iup iup:) srfi-18)

(define *queue* '())
(define *queue-mutex* (make-mutex))

(define (process-queue)
 (for-each (lambda (entry)(entry))(reverse *queue*))
 (print "processed queue")
 (set! *queue* '()))

(define (iattr . params)
 (mutex-lock! *queue-mutex*)
 (if (not (null? *queue*))
 (process-queue))
 (let ((result (apply iup:attribute params)))
   (mutex-unlock! *queue-mutex*)
   result))

(define (iattr-set! . params)
 (mutex-lock! *queue-mutex*)
 (set! *queue* (cons (lambda ()(apply iup:attribute-set! params)) 
*queue*))

 (mutex-unlock! *queue-mutex*))

(define button1 (iup:button
"Push me"
action: (lambda (o)
  (print "Got here at " (current-seconds))
  (iattr-set! o "BGCOLOR" "255 255 255"

(define tl (iup:show
   (iup:dialog
(iup:vbox
 button1
 (iup:button "Exit" action: (lambda (o)(exit)))

(define (main)
 (let* ((th1 (make-thread (lambda ()
(let loop ()
  (mutex-lock! *queue-mutex*)
  (process-queue)
  (mutex-unlock! *queue-mutex*)
  (iup:main-loop-flush)
  (thread-sleep! 1) ;; use a really long delay just for
illustration
  (loop)))
  "flush loop"))
(th2 (make-thread (lambda ()
(let loop ()
  (print "set to green")
  (iattr-set! button1 "BGCOLOR" "70 249 73")
  (thread-sleep! 0.2)
  (print "set to red")
  (iattr-set! button1 "BGCOLOR" "253 33 49")
  (thread-sleep! 0.2)
  (loop)
(th3 (make-thread (lambda ()
(let loop ()
  (print (iattr button1 "BGCOLOR"))
  (thread-sleep! (random 5))
  (loop))
   (thread-start! th1)
   (thread-start! th2)
   (thread-start! th3)
   (thread-join! th1)))

(main)




Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

2018-04-19 Thread Jörg F . Wittenberger

Eric,

sorry, you missunderstood my proposed solution.

I wanted to suggest to NOT put additional events into whatever queue Iup 
uses behind the scenes.


Instead better maintain you own queue and process this before you complete 
Iup's queue once using IupFlush.


On Apr 18 2018, Eric Wing wrote:



It's easy to see the problem you're facing.

I'm no IUP expert, however I'm pretty positive that this can be solved
without introducing another API.

In a similar situation I have been able to abstain from using the 
complete IUP abstraction around the main loop and resort to using 
IupFlush() instead. Doing so allows to queue requests from other threads 
for execution


in the GUI thread, which processes said queue right before calling
IupFlush().

Once I had these roughly 40 lines of code in place begin factoring out
IupFlush()s and run them just once before IupFlush() to reduce some
flickering.

Maybe such an approach can work for you too.



Thanks for the idea. But I don't think IupFlush() addresses the problem.

IupFlush() solves a problem of needing to process a request
immediately already in the event queue.

But the missing piece of the puzzle is *how to put an event (from
another thread) into the event queue*.





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

2018-04-18 Thread Jörg F . Wittenberger

Hi,

just my two cents.

On Apr 16 2018, Eric Wing wrote:


This is a proposal to introduce a way to post and run events on the
main UI thread.

Currently (as far as I know), IUP is hands-off on threads.


...

It's easy to see the problem you're facing.

I'm no IUP expert, however I'm pretty positive that this can be solved 
without introducing another API.


In a similar situation I have been able to abstain from using the complete 
IUP abstraction around the main loop and resort to using IupFlush() 
instead. Doing so allows to queue requests from other threads for execution 
in the GUI thread, which processes said queue right before calling 
IupFlush().


Once I had these roughly 40 lines of code in place begin factoring out 
IupFlush()s and run them just once before IupFlush() to reduce some 
flickering.


Maybe such an approach can work for you too.

Best

/Jörg




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] 7GUIs GUI comparison

2017-11-18 Thread Jörg F . Wittenberger

On Nov 17 2017, Eric Wing wrote:


On 11/17/17, Antonio Scuri  wrote:

  Very interesting indeed.

  I think we should implement those samples in C and Lua.

Best,
Scuri



I also think LED example alternatives would be valuable too. A lot of
frameworks now allow layout to be done separate from code, so people
like to see how to do both pure-programmatically and with the layout
builders.

So with IUP, people would probably be interested in seeing LED
variants in addition to the pure code solution (especially those
planning to work with IUP in more-verbose/less-script-y languages like
C (as opposed to Lua)).


Furthermore lets not forget that the 7gui and related thesis work is kind 
of a simplicity shootout. People new to IUP will certainly value its 
portability but also consider the price tag. The easier it is to get 
something done, the better it is.


Hence I'd suggest to find a prominent place for those bindings to other 
languages of users choice in the iup documentation anyways. After all it 
exemplifies adoption and demonstrates flexibility.


On a personal note wrt. the "simpicity shootout" I'd even recommend to look 
at those Chicken bindings. I found them quite nice. Actually it's for those 
bindings that I'm using Iup at all. The portability is nice; I never tried 
it on anything but Linux so far.


Best

/Jörg







--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)

2017-01-09 Thread Jörg F . Wittenberger
Hi all,

let me add my $ 0.02 here.

On Jan 8 2017, Andrew Robinson wrote:

>Hi Eric,
>
> IUP is extremely healthy the way it is now, so protecting IUP's health is 
> the more important of all things to consider.
> 
> Talking about the different specific event loops is like talking about 
> apples and oranges.

I do NOT share your hard feelings towards the proposal.

Without knowing enough of the IUP internals to judge how hard it would be 
to actually implement it, I had the impression that the proposal was well 
thought out and would broaden the applicability of IUP. And at least IMHO 
it looks as if there is little actual damage done.

I myself learned already before to work AROUND the limitation of IUP 
expecting to assume control of the event loop of the application. And that 
is for a pure C+Linux application (which assumes to mostly sit in poll(2) 
and revolves around invoking callbacks when data is available). I wonder 
how many people ran into those issues too.

Furthermore I'd also welcome IUP support for iOS or Android. Though I'd 
agree with Andrew: if that came at the cost of becoming a non-maintainable 
bloatware, I'd rather choose the path of simplicity.

Best

/Jörg


..



--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


[Iup-users] code suggestion

2016-01-02 Thread Jörg F . Wittenberger
in iup/srcweb/config.mak around line 21 insert something like

ifneq ($(findstring Linux4, $(TEC_UNAME)), )
  USE_GTK3 = Yes
  LIBS += webkitgtk-3.0
  INCLUDES += $(GTK)/include/webkitgtk-3.0
else


(and close the ifneq 11 lines later).


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


[Iup-users] a bug I can't resolve myself

2016-01-02 Thread Jörg F . Wittenberger
preliminary web search suggests that -lX11 is missing somewhere.

Though I can't find out where to add it.

(Raspberian, gtk 3.0)



Tecmake: linking iuplua51 ...
g++ -o ../bin/Linux41/Lua51/iuplua51
../obj/iuplua51/Linux41/Lua51/iup_lua.o
../lib/Linux41/Lua51/libiuplua51.a
/usr/lib/arm-linux-gnueabihf//liblua5.1.a ../lib/Linux41/libiup.a -Wl,-E
 -ldl -lm -lgtk-3 -latk-1.0 -lgio-2.0 -lgdk-3 -lpangocairo-1.0
-lpango-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgobject-2.0
-lglib-2.0
/usr/bin/ld: ../lib/Linux41/libiup.a(iupunix_info.o): undefined
reference to symbol 'XGetWindowAttributes'
//usr/lib/arm-linux-gnueabihf/libX11.so.6: error adding symbols: DSO
missing from command line
collect2: error: ld returned 1 exit status
../tecmake.mak:1543: recipe for target '../bin/Linux41/Lua51/iuplua51'
failed
make[2]: *** [../bin/Linux41/Lua51/iuplua51] Error 1
Makefile:11: recipe for target 'iuplua5' failed
make[1]: *** [iuplua5] Error 2
Makefile:41: recipe for target 'iupconsole' failed



--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] building iup from sources

2016-01-02 Thread Jörg F . Wittenberger
Me too ;-)

I did some deb packaging in the past.  But I can#t claim that I'm very
experienced with this.  To the contrary.

If I had a less hard time to get iup compiled at all, I had packaged it
already.  But as it is, I don't foresee me succeeding in a reasonable
timespan.


Am 02.01.2016 um 12:18 schrieb James Fuller:
> I would really like to see a Ubuntu MATE (for PI 2) implantation of the
> iup,cd,im libraries.
> Ubuntu MATE (for PI 2) has wxWidgets in the repository and I have had some
> success using it but I would
> like to use something with a smaller footprint and with c not c++.
> 
> James


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] Is Iup pthread safe?

2015-10-06 Thread Jörg F. Wittenberger
Am 06.10.2015 um 12:25 schrieb Ranier VF:
> Hi,Well, your implementation must be:one consumer (GUI thread)many producers 
> (GUI events)
> You can use mutex-condition pair (classic), sockets or a new way pipes.

As I understand Andys question he wants to know how to unblock the GUI
thread while it is waiting in IupMainLoop.  Correct?

That's actually I problem I have as well.  My work around is to use
IupFlush instead of the main loop.  But that's a bit against Antonios
suggestions.

Best
/Jörg


> Best,Ranier Vilela
> 
>> From: supp...@scriptbasic.org
>> To: iup-users@lists.sourceforge.net
>> Date: Mon, 5 Oct 2015 22:17:15 -0700
>> Subject: Re: [Iup-users] Is Iup pthread safe?
>>
>> Andy,
>>
>> I feel if you follow what I have done in Script BASIC for threaded IUP
>> it should work for you without any changes to anything.
>>
>> John
>>
>> On Tue, 2015-10-06 at 15:54 +1100, Andy Xiyue wrote:
>>> Thanks John and Ranier.
>>>
>>>
>>> At least I'm confirmed now I can not update the attributions of IUP
>>> controls in other threads so my previous programming module was
>>> definitely wrong. 
>>>
>>> So the question becomes how to send the control update event to the
>>> main thread?
>>>
>>>
>>> It's quite obvious the main thread is stuck in IupMainLoop(). Most
>>> events can be processed in this main thread, like buttons, text, etc.
>>> When users click the button, or inside the text input entry, the IUP
>>> generates the event and it will be processed in IupMainLoop().
>>> However, how an external thread send the event into the main thread? I
>>> can't use message queue or semaphore because IupMainLoop() takes all
>>> the control. Are there some functions used for inserting IUP events?
>>>
>>>
>>> Kind regards
>>>
>>> Andy
>>>
>>> --
>>> ___
>>> Iup-users mailing list
>>> Iup-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/iup-users
>>
>>
>>
>> --
>> ___
>> Iup-users mailing list
>> Iup-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/iup-users
> 
> 
> 
> 
> --
> 
> 
> 
> ___
> Iup-users mailing list
> Iup-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iup-users
> 


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] UTF-8 GTK2/Linux: action callback in IupText broken.

2015-09-21 Thread Jörg F. Wittenberger
Am 20.09.2015 um 21:05 schrieb Antonio Scuri:
>   Because of the console default locale. In Windows it is not UTF-8. In
> modern Linux, at least in Ubuntu the default is UTF-8. So it should work.
> I'll make a few tests here next week and let you know.

I see.  Now this is a Debian/Testing here and the locale is configured
to UTF-8.

But as mentioned: it's not only on the debug output, the control itself
ended up with the mangled content too.

Best

/Jörg

> 
> Best,
> Scuri
> 
> 
> On Sat, Sep 19, 2015 at 7:13 AM, "Jörg F. Wittenberger" <
> joerg.wittenber...@softeyes.net> wrote:
> 
>> Am 18.09.2015 um 22:03 schrieb Antonio Scuri:
>>>   I think that won't work. It will print garbage... Specially in Windows.
>>
>> Out of curiosity: why will it print garbage?
>>
>> (BTW: In the case at hand it's not Windows. As I noted: I've been able
>> to bypass the issue.)
>>
>> The symptom was NOT exclusively seen in the printf debug output.  The
>> same mangled string was displayed by the IupText control.
>>
>> Best
>>
>> /Jörg
>>
>>>
>>> Best,
>>> Scuri
>>>
>>>
>>> On Fri, Sep 18, 2015 at 4:55 PM, "Jörg F. Wittenberger" <
>>> joerg.wittenber...@softeyes.net> wrote:
>>>
>>>> Am 17.09.2015 um 02:34 schrieb Antonio Scuri:
>>>>>   How are you checking this? Using a printf like output?
>>>>
>>>> Exactly.  Sitting in the action callback I fed the new_value pointer to
>>>> printf(stderr, "SearchV: \"%s\"\n", new_value);
>>>>
>>>>
>>>>>
>>>>>   I couldn't reproduce the problem here.
>>>>>
>>>>> Best,
>>>>> Scuri
>>>>>
>>>>>
>>>>> On Thu, Aug 27, 2015 at 10:21 AM, Antonio Scuri <
>>>> sc...@tecgraf.puc-rio.br>
>>>>> wrote:
>>>>>
>>>>>>   ok I'll check that.
>>>>>>
>>>>>> Thanks,
>>>>>> Scuri
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 26, 2015 at 6:22 PM, "Jörg F. Wittenberger" <
>>>>>> joerg.wittenber...@softeyes.net> wrote:
>>>>>>
>>>>>>> I'm trying to use the ACTION callback on a IupText.  The callback
>>>>>>> receives wierd values for the 3rd (char* new_value) argument.
>>>>>>>
>>>>>>> Here what I get when I enter "merkwürdig":
>>>>>>>
>>>>>>> SearchV: "m"
>>>>>>> SearchV: "me"
>>>>>>> SearchV: "mer"
>>>>>>> SearchV: "merk"
>>>>>>> SearchV: "merkw"
>>>>>>> SearchV: "merkwü"
>>>>>>> SearchV: "merkw�r�"
>>>>>>> SearchV: "merkwüdr"
>>>>>>> SearchV: "merkwürid"
>>>>>>> SearchV: "merkwürdgi"
>>>>>>>
>>>>>>> The "ü" character is first damaged, then restored.  Worse: from now
>> on
>>>>>>> the last two characters are always kept swapped.
>>>>>>>
>>>>>>> The problem worsens to total mess when I enter two UTF-8 characters.
>>>>>>>
>>>>>>>
>>>>>>> I've been able to work around the problem by ignoring the ACTION
>>>>>>> callback and retrieving the current value in VALUECHANGED_CB.
>>>>>>>
>>>>>>> Just wanted to inform you about the issue.
>>>>>>>
>>>>>>> Best
>>>>>>>
>>>>>>> /Jörg


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] IupRefresh - how to use it properly

2015-09-09 Thread Jörg F. Wittenberger
Am 02.09.2015 um 19:18 schrieb Antonio Scuri:
>IupRefresh does not affects a single control. It affects all the dialog.
> All the dialog layout, for all controls inside it, is recomputed when
> IupRefresh is called, even is the parameter is a label deep down the dialog
> hierarchy. If for every change you are calling IupRefresh, then do it only
> once at the end of all changes. Is that the case?

Thanks a lot.  That's been the case.  Whenever I'm unsure I now use
IupGetDialog to find the dialog (or non) to refresh and collect the
refresh requests per application-activity.  Much better.

Best

/Jörg

--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


[Iup-users] IupRefresh - how to use it properly

2015-08-29 Thread Jörg F. Wittenberger
Hi,

the subject say it all.  I need some better understanding when there
should be a refresh and when not.

I gather IupRefresh is for re-calculating the size of objects.  (Correct?)

Thus when I change say the TITLE attribute of a IupLabel, then the label
may become larger, have a different number of lines etc. and thus there
should an IupRefresh following.  (Still correct?)

Same applies to say adding/removing elements.

So far summarized: whenever something changes and I'm not completely
sure that this does not affect size, I rather should follow up with an
IupRefresh.  ??


This policy however is not as viable as I'd like it to be.  Having to
update a simple listing of around 100 Iupcontrols became unbearable
slow.  Turns out on my machine running this simple app a single
IupRefresh takes something between 50ms and 200ms.  Has me waiting
several seconds for a stable result.  Hence I need to conserve IupRefresh's.


So which refresh operations should I keep?  Somehow the docs suggest
that any one IupRefresh on any element should be enough.  Is this
correct?  (((Asking this because my experiments suggest that it's not
enough, but this is not conclusive yet - maybe something else is wrong
with the experiment.  After all issues don't arise until there are
enough controls and activity.  So maybe my experiment is flawed.)))

Thanks

/Jörg

--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] Normalizers

2015-08-26 Thread Jörg F. Wittenberger
I figured out that I can force those normalizers to get up on their hind
legs and beg.

All I have to do is: remove some size-attribute.

If I either set SIZE or RASTERSIZE to NULL than I get the normalization
again.

(Now I have visual effects, which is not so good either.  But I have
hope to eventually learn how to best cope with those.)

But which of the size attributes SHOULD I actually set to NULL?

Thanks

/Jörg

Am 26.08.2015 um 17:28 schrieb Jörg F. Wittenberger:
 Hi,
 
 it seems that the normalizers don't like me.
 
 I created a matrix from vbox/hbox having a label and a multiline text.
 All labels added to a normalizer.
 
 When I set the NORMALIZE to HORIZONTAL the first time all works well and
 the left column has the correct width.
 
 Than I change all the titles of those labels and again set the normalize
 attribute on the normalizer.
 
 Still the labels keep their width.
 
 What am I possibly missing?  (I already messed around calling additional
 IupRefresh's the modified labels, but this did not yield the desired
 effect.)
 
 Thanks a lot
 
 /Jörg


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


[Iup-users] UTF-8 GTK2/Linux: action callback in IupText broken.

2015-08-26 Thread Jörg F. Wittenberger
I'm trying to use the ACTION callback on a IupText.  The callback
receives wierd values for the 3rd (char* new_value) argument.

Here what I get when I enter merkwürdig:

SearchV: m
SearchV: me
SearchV: mer
SearchV: merk
SearchV: merkw
SearchV: merkwü
SearchV: merkw�r�
SearchV: merkwüdr
SearchV: merkwürid
SearchV: merkwürdgi

The ü character is first damaged, then restored.  Worse: from now on
the last two characters are always kept swapped.

The problem worsens to total mess when I enter two UTF-8 characters.


I've been able to work around the problem by ignoring the ACTION
callback and retrieving the current value in VALUECHANGED_CB.

Just wanted to inform you about the issue.

Best

/Jörg

--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


[Iup-users] Normalizers

2015-08-26 Thread Jörg F. Wittenberger
Hi,

it seems that the normalizers don't like me.

I created a matrix from vbox/hbox having a label and a multiline text.
All labels added to a normalizer.

When I set the NORMALIZE to HORIZONTAL the first time all works well and
the left column has the correct width.

Than I change all the titles of those labels and again set the normalize
attribute on the normalizer.

Still the labels keep their width.

What am I possibly missing?  (I already messed around calling additional
IupRefresh's the modified labels, but this did not yield the desired
effect.)

Thanks a lot

/Jörg

--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] How to help debug this segfault?

2015-08-11 Thread Jörg F. Wittenberger
Sorry for following up on my own message.

I just considered the problem again and got stuck.

Am 11.08.2015 um 14:04 schrieb Jörg F. Wittenberger:
 Am 10.08.2015 um 19:20 schrieb Antonio Scuri:
   Well, I really don't know.

   Just know that the calls are not actually active all at the same time.
 When you call IupFlush in one of them, it will stop that one, processes the
 pending messages one by one, then return to that one. If that can occur
 recursively then it is a real nightmare to manage. You will have a hard
 time to know what is the order that things are happening.
 
 Ah' I see.

Maybe I don't really see.

So when exactly SHOULD I call IupFlush?  Which one is the strategy
natural to Iup.  Changing the app side of things is simple.  There is
not so much to change by now.  I'm still exploring/learning the toolkit.

So far the first strategy I tried was to simply run IupMainLoop and call
Iup functions from the callbacks.

This did work as long as there Iup was the only source of events to be
considered.  But there is some i/o going on (database connections etc.).
 So I switched to the next strategy :

2nd: In a loop
  1. Call all Iup* things to build the GUI as app logic suggests at this
point in time.
  2. Call IupFlush.  (Former version: call IupLoopStep and IupFlush if
that does not return IUP_CLOSE, but that seemed to add no value over
just IupFlush.)
  3. Poll other I/O for a moment.  Goto 1 processing the results.

This did work most of the time, but sometimes it would just not result
in updates as expected.  Turned out some calls (I don't recall which one
it where) would executed in (1.) call callbacks again.  (I recall having
read about this in the docs, so no surprise here so far.)

At this point I had to do wild guess work how I should handle this.

Option A:  Record the callbacks job to be execute later and return
immediately.
Option B: Execute the Job right now.

The former resulted eventually in the segfaults during IupFlush in step
(2).  To I settled so far on Option B.  But this required me to Call
IupFlush also in the recursive invocation.


So, to repeat myself: which strategy is natural to Iup?

When must I call IupFlush?

As I'm reading your reply, I'd understand that calling IupFlush from
withing callbacks is no good idea, correct?

If so: how would I make those changes take effect?  Because: if I call
too many (whatever that is _I_ have no way to know) Iup* things (e.g.
IupDestroy) from within a single callback, then I get the segfault.


Thanks so much

/Jörg


 
 Maybe it's a good idea to add a remark pointing this out in the manual.
  Me, reading the manual, gathered that calling IupFlush would never
 hurt, just advance the processing at the Iup side of things.
 
   I would recommend you to get a step back are rethink that strategy.
 
 So far this never became a strategy.  It failed straight in the first
 experiment.  It's just my missunderstanding of the docs and an experiment.
 
 Independent from IUP, or other toolkits, what you are trying to implement?
 
 There is a very simple RDF/DublinCore inspired inventory application for
 a small archive (archive of physical things, kind of a museum - not the
 family of file formats).  I'm using it as personal wiki for my notes too.
 
 The original is a web app.  I'm trying replace the Web-Interface with a
 native GUI.
 
 /Jörg
 
 
 Best,
 Scuri


 On Sat, Aug 8, 2015 at 9:58 AM, Jörg F. Wittenberger 
 joerg.wittenber...@softeyes.net wrote:

 ((Sorry, this is not exactly the message I want to reply to, but at
 least it's the correct thread.  (The other message is already gone here.)))

 I managed to understand the problem a little better.

 Maybe I'm dong something against the philosophy of correct Iup usage here?

 What's happened is that the action callback from my apps back-button is
 called as often as I click it.  Eventually my action callback will also
 call IupFlush.  (Is this a No-No?)  This IupFlush in turn enables the
 next action callback to be activated.  Thus there are 4-5 calls active
 at the same time.

 Each of those calls does essentially the same: recreate scrollbox full
 of controls (from different data sets).  Then detach the (only) child of
 the target container, IupDestroy that detached child, IupAppend the new
 one and IupRefresh the container.

 Since the data set is different, those action callback take a different
 amount of time (while waiting for the data base etc.).

 By throwing in some additional calls to IupFlush into the code (I'd
 believe this _should_ not hurt, shouldn't it?) I've been able to get it
 all mixed up.  Up to the point that controls belonging to different data
 sets / callbacks ended up mixed into the same container.

 To put it in other words: those nested action callbacks in combination
 with IupFlush enabled me to (accidentally) implement a kind of green
 threads on top of Iup.  Unfortunately without proper locking.

 Having too few IupFlush's there will result in the segfault

Re: [Iup-users] How to help debug this segfault?

2015-08-11 Thread Jörg F. Wittenberger
Am 11.08.2015 um 16:31 schrieb Jörg F. Wittenberger:
 Am 11.08.2015 um 16:27 schrieb Antonio Scuri:
   Maybe you can try the IDLE and see how it behaves.

   There is also another possibility. The IDLE callback is somewhat
 equivalent of

 while(IupLoopStep() != IUP_CLOSE)
 {
   do something
 }
 
 Not too bad.  Though that's essentially the loop my program is sitting in.
 
 do something would be in my app 1. do Iup-Calls 2. poll i/o
 
 But if I don't have *any* IupFlush in there, than I don't see any
 progress ever.  That's confusing me.

Turns out that's not completely true.

If do something does wait some time, than I'm in the same position as
if IupMailLoop would simply sit idle until it fires the timer.

In practice: it takes forever.


 
 
   But this is also high CPU consuming.

   So, to avoid this, you can try:

 while(IupLoopStepWait() != IUP_CLOSE)
 {
   do something
 }

   But I would start with the IDLE. In GTK is much better handled than in
 Windows.

 Best,
 Scuri


 On Tue, Aug 11, 2015 at 11:09 AM, Jörg F. Wittenberger 
 joerg.wittenber...@softeyes.net wrote:

 Sorry again.

 I've been distracted and did not read to the end of your message.

 Am 11.08.2015 um 15:39 schrieb Antonio Scuri:
   Ok. Now I see.

   IupFlush is usually used when you need to processes messages after
 changing elements attributes that need to be updated by the system.

   I would recommend using IupMainLoop and something else for the database
 connections, not the way around using IupFlush.

  There are several ways how to pool secondary systems:

 - Use a second thread to processes it (frequently used)

 That's the complicated way I can see.  Have an embeddes
 Lua-Interpreter executed dynamically generated Lua code.

 - Use a IupTimer to check from time to time if there is something to be
 processed on it (limited by a minimum time interval for not too fast
 processing)

 That's what we startet with.  But since I can't make the timer return
 right now, it will hopelessly slow down the application.  To no
 usable.  Example: e few hundred results to be read from the database and
 display in a matrix.  Takes forever while Iup is sitting most of the
 time in idle until the timer will check for i/o and notice a new item.

 - Use the IDLE callback to process it (high CPU use since it will be
 running all the time)

 As you said: that's the CPU hook.  I read that in the docs and thought
 there must be a better way.

 Sorry again for the incomplete reply before.

 /Jörg


 Best,
 Scuri




 On Tue, Aug 11, 2015 at 10:11 AM, Jörg F. Wittenberger 
 joerg.wittenber...@softeyes.net wrote:

 Sorry for following up on my own message.

 I just considered the problem again and got stuck.

 Am 11.08.2015 um 14:04 schrieb Jörg F. Wittenberger:
 Am 10.08.2015 um 19:20 schrieb Antonio Scuri:
   Well, I really don't know.

   Just know that the calls are not actually active all at the same
 time.
 When you call IupFlush in one of them, it will stop that one,
 processes
 the
 pending messages one by one, then return to that one. If that can
 occur
 recursively then it is a real nightmare to manage. You will have a
 hard
 time to know what is the order that things are happening.

 Ah' I see.

 Maybe I don't really see.

 So when exactly SHOULD I call IupFlush?  Which one is the strategy
 natural to Iup.  Changing the app side of things is simple.  There is
 not so much to change by now.  I'm still exploring/learning the toolkit.

 So far the first strategy I tried was to simply run IupMainLoop and call
 Iup functions from the callbacks.

 This did work as long as there Iup was the only source of events to be
 considered.  But there is some i/o going on (database connections etc.).
  So I switched to the next strategy :

 2nd: In a loop
   1. Call all Iup* things to build the GUI as app logic suggests at this
 point in time.
   2. Call IupFlush.  (Former version: call IupLoopStep and IupFlush if
 that does not return IUP_CLOSE, but that seemed to add no value over
 just IupFlush.)
   3. Poll other I/O for a moment.  Goto 1 processing the results.

 This did work most of the time, but sometimes it would just not result
 in updates as expected.  Turned out some calls (I don't recall which one
 it where) would executed in (1.) call callbacks again.  (I recall having
 read about this in the docs, so no surprise here so far.)

 At this point I had to do wild guess work how I should handle this.

 Option A:  Record the callbacks job to be execute later and return
 immediately.
 Option B: Execute the Job right now.

 The former resulted eventually in the segfaults during IupFlush in step
 (2).  To I settled so far on Option B.  But this required me to Call
 IupFlush also in the recursive invocation.


 So, to repeat myself: which strategy is natural to Iup?

 When must I call IupFlush?

 As I'm reading your reply, I'd understand that calling IupFlush from
 withing callbacks is no good idea, correct?

 If so: how would I make those changes take

Re: [Iup-users] How to help debug this segfault?

2015-08-11 Thread Jörg F. Wittenberger
Am 11.08.2015 um 16:27 schrieb Antonio Scuri:
   Maybe you can try the IDLE and see how it behaves.
 
   There is also another possibility. The IDLE callback is somewhat
 equivalent of
 
 while(IupLoopStep() != IUP_CLOSE)
 {
   do something
 }

Not too bad.  Though that's essentially the loop my program is sitting in.

do something would be in my app 1. do Iup-Calls 2. poll i/o

But if I don't have *any* IupFlush in there, than I don't see any
progress ever.  That's confusing me.


   But this is also high CPU consuming.
 
   So, to avoid this, you can try:
 
 while(IupLoopStepWait() != IUP_CLOSE)
 {
   do something
 }
 
   But I would start with the IDLE. In GTK is much better handled than in
 Windows.
 
 Best,
 Scuri
 
 
 On Tue, Aug 11, 2015 at 11:09 AM, Jörg F. Wittenberger 
 joerg.wittenber...@softeyes.net wrote:
 
 Sorry again.

 I've been distracted and did not read to the end of your message.

 Am 11.08.2015 um 15:39 schrieb Antonio Scuri:
   Ok. Now I see.

   IupFlush is usually used when you need to processes messages after
 changing elements attributes that need to be updated by the system.

   I would recommend using IupMainLoop and something else for the database
 connections, not the way around using IupFlush.

  There are several ways how to pool secondary systems:

 - Use a second thread to processes it (frequently used)

 That's the complicated way I can see.  Have an embeddes
 Lua-Interpreter executed dynamically generated Lua code.

 - Use a IupTimer to check from time to time if there is something to be
 processed on it (limited by a minimum time interval for not too fast
 processing)

 That's what we startet with.  But since I can't make the timer return
 right now, it will hopelessly slow down the application.  To no
 usable.  Example: e few hundred results to be read from the database and
 display in a matrix.  Takes forever while Iup is sitting most of the
 time in idle until the timer will check for i/o and notice a new item.

 - Use the IDLE callback to process it (high CPU use since it will be
 running all the time)

 As you said: that's the CPU hook.  I read that in the docs and thought
 there must be a better way.

 Sorry again for the incomplete reply before.

 /Jörg


 Best,
 Scuri




 On Tue, Aug 11, 2015 at 10:11 AM, Jörg F. Wittenberger 
 joerg.wittenber...@softeyes.net wrote:

 Sorry for following up on my own message.

 I just considered the problem again and got stuck.

 Am 11.08.2015 um 14:04 schrieb Jörg F. Wittenberger:
 Am 10.08.2015 um 19:20 schrieb Antonio Scuri:
   Well, I really don't know.

   Just know that the calls are not actually active all at the same
 time.
 When you call IupFlush in one of them, it will stop that one,
 processes
 the
 pending messages one by one, then return to that one. If that can
 occur
 recursively then it is a real nightmare to manage. You will have a
 hard
 time to know what is the order that things are happening.

 Ah' I see.

 Maybe I don't really see.

 So when exactly SHOULD I call IupFlush?  Which one is the strategy
 natural to Iup.  Changing the app side of things is simple.  There is
 not so much to change by now.  I'm still exploring/learning the toolkit.

 So far the first strategy I tried was to simply run IupMainLoop and call
 Iup functions from the callbacks.

 This did work as long as there Iup was the only source of events to be
 considered.  But there is some i/o going on (database connections etc.).
  So I switched to the next strategy :

 2nd: In a loop
   1. Call all Iup* things to build the GUI as app logic suggests at this
 point in time.
   2. Call IupFlush.  (Former version: call IupLoopStep and IupFlush if
 that does not return IUP_CLOSE, but that seemed to add no value over
 just IupFlush.)
   3. Poll other I/O for a moment.  Goto 1 processing the results.

 This did work most of the time, but sometimes it would just not result
 in updates as expected.  Turned out some calls (I don't recall which one
 it where) would executed in (1.) call callbacks again.  (I recall having
 read about this in the docs, so no surprise here so far.)

 At this point I had to do wild guess work how I should handle this.

 Option A:  Record the callbacks job to be execute later and return
 immediately.
 Option B: Execute the Job right now.

 The former resulted eventually in the segfaults during IupFlush in step
 (2).  To I settled so far on Option B.  But this required me to Call
 IupFlush also in the recursive invocation.


 So, to repeat myself: which strategy is natural to Iup?

 When must I call IupFlush?

 As I'm reading your reply, I'd understand that calling IupFlush from
 withing callbacks is no good idea, correct?

 If so: how would I make those changes take effect?  Because: if I call
 too many (whatever that is _I_ have no way to know) Iup* things (e.g.
 IupDestroy) from within a single callback, then I get the segfault.


 Thanks so much

 /Jörg



 Maybe it's a good idea to add a remark pointing this out

Re: [Iup-users] How to help debug this segfault?

2015-08-08 Thread Jörg F. Wittenberger
((Sorry, this is not exactly the message I want to reply to, but at
least it's the correct thread.  (The other message is already gone here.)))

I managed to understand the problem a little better.

Maybe I'm dong something against the philosophy of correct Iup usage here?

What's happened is that the action callback from my apps back-button is
called as often as I click it.  Eventually my action callback will also
call IupFlush.  (Is this a No-No?)  This IupFlush in turn enables the
next action callback to be activated.  Thus there are 4-5 calls active
at the same time.

Each of those calls does essentially the same: recreate scrollbox full
of controls (from different data sets).  Then detach the (only) child of
the target container, IupDestroy that detached child, IupAppend the new
one and IupRefresh the container.

Since the data set is different, those action callback take a different
amount of time (while waiting for the data base etc.).

By throwing in some additional calls to IupFlush into the code (I'd
believe this _should_ not hurt, shouldn't it?) I've been able to get it
all mixed up.  Up to the point that controls belonging to different data
sets / callbacks ended up mixed into the same container.

To put it in other words: those nested action callbacks in combination
with IupFlush enabled me to (accidentally) implement a kind of green
threads on top of Iup.  Unfortunately without proper locking.

Having too few IupFlush's there will result in the segfault.  More
flushes make it appear to work.  Even more flushes confuse the layout logic.

How should this being done right?

Thanks

/Jörg

Am 05.08.2015 um 10:50 schrieb Jörg F. Wittenberger:
 Hi Antonio,
 
 during IupFlush my program dumped a core like this:
 
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  0x4097693a in gtkCanvasSetDXAttrib.part.3 () from
 /usr/local/lib/libiup.so
 (gdb) bt
 #0  0x4097693a in gtkCanvasSetDXAttrib.part.3 () from
 /usr/local/lib/libiup.so
 #1  0x in ?? ()
 
 
 Anything I can do to help debugging that one?
 
 Best
 
 /Jörg


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] A bag of questions.

2015-08-07 Thread Jörg F. Wittenberger
More Info:

I've got a text without a border - as I want it.  It works for
multiline=yes.  Seems that only the combination of multiline=No and
border=No is not working for me.

Am 04.08.2015 um 17:00 schrieb Antonio Scuri:
   I just tested BORDER under Windows, GTK2 (Ubuntu 10) and GTK3 (Ubuntu
 14). And they all work fine. But notice that border is a creation only
 attribute, so it must be set before mapping into the native system. The
 Milind example does that.


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


[Iup-users] IupText with wordwrap=yes

2015-08-07 Thread Jörg F. Wittenberger
Hi,

I've got little success to get IupText with wordrwap=yes (and
mutliline=yes) to work.

I want the multiline text to be large enough to hold all the text (i.e.,
no vertical scroll bar), but _not_ expand=yes so it's not using more
space than required.

I'e got this working with expand=no and a map_cb, which sets
VISIBLELINES to the value of the LINECOUNT attribute.  (I could have
counted those lines myself and set visiblelines right from the start,
but...) I intented this to work for wordwrap=yes as well.  But it does not.

At this point I don't see how to control the vertical space for
wordwrap'ed text.

Thanks for any hint.

/Jörg

--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] A bag of questions.

2015-08-07 Thread Jörg F. Wittenberger
I just tripple-checked my code, it never tries to change the border
after mapping.  Only right after creation.  Even before requesting
multiline=yes - which works.  (Debian, gtk2)

So the problem must be something else.  But how to nail it?

/Jörg

Am 04.08.2015 um 17:00 schrieb Antonio Scuri:
   I just tested BORDER under Windows, GTK2 (Ubuntu 10) and GTK3 (Ubuntu
 14). And they all work fine. But notice that border is a creation only
 attribute, so it must be set before mapping into the native system. The
 Milind example does that.


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] How to help debug this segfault?

2015-08-06 Thread Jörg F. Wittenberger
Am 05.08.2015 um 16:31 schrieb Antonio Scuri:
   Can you list the call stack up to that point?

That's been more tricky than expected.

   IupFlush will not change other IUP calls, but it may trigger system
 events that actually do some IUP calls too. So, if the IUP canvas is being
 destroyed while IupFlush triggered the events, then Yes, it will crash.

I'm seeing a sequence of IupRefresh's followed by IupDestroy's.  No
refresh to handles after they've been destroyed.

However the IupFlush is called only every so often.  (Normally either
every 150ms or once *all* pending Iup* calls from the application are
processed.)

In practice I've seen up to 4 refresh and destroys until the next
IupFlush was called.

That IupFlush does segfault.

That's something I'd rather love not to have.  I'd prefer invalid calls
to be rejected via return code.  Or at least the very call fail - even
by a segfault - which is called with invalid parameters.   But a
segfault after handful of successfully accepted calls later - that's
hard to debug.

For now I've found a workaround: just insert IupFlush's after every
Iup*whatever call.  This does at least not segfault.

But it's nowhere near perfection.  I can feel the app being slowed down
now.  And it flickers now, intermediately drawing wrong sized controls
over perfect areas just to update them a split second later.

/Jörg

 
 Scuri
 
 
 On Wed, Aug 5, 2015 at 10:58 AM, Jörg F. Wittenberger 
 joerg.wittenber...@softeyes.net wrote:
 
 What does it mean that the canvas is still valid?  (This seems to hint
 to the point.)  I presume it's valid until IupDestroy'ed.

 This happens to me when I use the back-button in my little app.  And
 only if I'm tripple-clicking it fast enough.

 The app will create a fresh ScrollBox (a canvas, I gather), fill it with
 results and push it to display.  Then it will proceed to handle the next
 button push doing the same thing again.

 Conceivably it could be faster than the update process inside iup.

 However all those updates are passed down the same queue in sequence.
 There is only one green thread, which would ever call IupFlush and
 {IupDetach+IupUnmap+IupDestroy (in this sequence)}.

 However if IupFlush would reorder requests... would it?

 Am 05.08.2015 um 15:42 schrieb Antonio Scuri:
  That is a highly used function in IupCanvas. So probably the problem is
 not there.

  What did you do before calling IupFlush. Is the canvas still valid
 during
 the flush?

 Best,
 Scuri


 On Wed, Aug 5, 2015 at 5:50 AM, Jörg F. Wittenberger 
 joerg.wittenber...@softeyes.net wrote:

 Hi Antonio,

 during IupFlush my program dumped a core like this:

 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  0x4097693a in gtkCanvasSetDXAttrib.part.3 () from
 /usr/local/lib/libiup.so
 (gdb) bt
 #0  0x4097693a in gtkCanvasSetDXAttrib.part.3 () from
 /usr/local/lib/libiup.so
 #1  0x in ?? ()


 Anything I can do to help debugging that one?

 Best

 /Jörg


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] How to help debug this segfault?

2015-08-05 Thread Jörg F. Wittenberger
What does it mean that the canvas is still valid?  (This seems to hint
to the point.)  I presume it's valid until IupDestroy'ed.

This happens to me when I use the back-button in my little app.  And
only if I'm tripple-clicking it fast enough.

The app will create a fresh ScrollBox (a canvas, I gather), fill it with
results and push it to display.  Then it will proceed to handle the next
button push doing the same thing again.

Conceivably it could be faster than the update process inside iup.

However all those updates are passed down the same queue in sequence.
There is only one green thread, which would ever call IupFlush and
{IupDetach+IupUnmap+IupDestroy (in this sequence)}.

However if IupFlush would reorder requests... would it?

Am 05.08.2015 um 15:42 schrieb Antonio Scuri:
  That is a highly used function in IupCanvas. So probably the problem is
 not there.
 
  What did you do before calling IupFlush. Is the canvas still valid during
 the flush?
 
 Best,
 Scuri
 
 
 On Wed, Aug 5, 2015 at 5:50 AM, Jörg F. Wittenberger 
 joerg.wittenber...@softeyes.net wrote:
 
 Hi Antonio,

 during IupFlush my program dumped a core like this:

 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  0x4097693a in gtkCanvasSetDXAttrib.part.3 () from
 /usr/local/lib/libiup.so
 (gdb) bt
 #0  0x4097693a in gtkCanvasSetDXAttrib.part.3 () from
 /usr/local/lib/libiup.so
 #1  0x in ?? ()


 Anything I can do to help debugging that one?

 Best

 /Jörg


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] A bag of questions.

2015-08-04 Thread Jörg F. Wittenberger
Am 04.08.2015 um 04:06 schrieb Milind Gupta:
 I didn't understand your requirements fully. But are you trying to achieve
 something that the lua program below does:
 
 --IupDialog Example in IupLua
 --Creates a simple dialog.
 
 require( iuplua )
 
 vbox = iup.vbox {
 iup.hbox{
 iup.label {title=Label},
 iup.text { border=NO; value=This is good;
 bgcolor=iup.GetGlobal(DLGBGCOLOR); readonly=YES; visiblecolumns=30 };
 gap=10
 }
 }
 dlg = iup.dialog{vbox; title=Dialog,size=QUARTERxQUARTER}
 dlg:show()
 
 if (iup.MainLoopLevel()==0) then
   iup.MainLoop()
 end

This is essentially what I'm doing.  Works OK for the simple case.

Maybe except that I'm seeing borders around the iup.text, which is my
first problem.

The second is with the positioning.  Using gridbox I'm trying to get the
left column to make all of the widest label visible.  But I can't figure
out how to achieve that.  I don't have to have gridbox there, but I'd
prefer vertical alignment for the second column.

The third is how to format the right hand side.  Often it's short text
too.  But there is also long single line text, which could really
benefit from word wrapping.  And there is text with embedded newlines,
which in turn needs to be displayed as is.  It's easy to use different
controls/arguments for each case.  But so far all but the short text do
strange things for me.


 On Mon, Aug 3, 2015 at 11:55 AM, Jörg F. Wittenberger 
 joerg.wittenber...@softeyes.net wrote:
 
 Hi,

 I'm trying to find a replacement formatting for what my current web app
 does using an html table.

 The table is simply two columns: a label in the left and value in the
 right column.

 I want/need it to look mostly like readable text, not so much like a
 separate GUI elements.

 At least the value side should allow to copy selected text into the
 clipboard.

 Initially I tried to do so using the label control.  But there seems
 to be no way to enable the text selection copying I need.

 So I switched to use the textbox control.  Somehow I can't get that
 right.  readonly works, but the attempt to remove the border (by
 creating it with border=No) fails.  It still has a border.  Using
 multiline with a single line of text seems to create at least two lines
 for the control.  Using wordwrap (which according to the docs would be
 something I want for my table) on it collapses it back to a single line
 but *adds* a scrollbar (for no reason I can see).

 Am I doing it all wrong?

 Is there a better way.  E.g., using label or something else?

 Furthermore I tried to format the table using gridbox.  I failed
 completely.

 Somehow I can't figure out how to tell the gridbox to expand the left
 column to fit the largest label.  How would I do this?  I tried
 FITTOCHILDREN=C0

 Another idea was to use the width of the strings and calculate a propper
 minsize for the elements (labels) in the left column of the gridbox.
 But how would I do this?  The length of the string does not match well
 to the actual width using proportional fonts.  And I failed to find a
 way to compute the width I should use.

 Thanks
 /Jörg

 BTW: I'm using the GTK driver under Linux.


 --
 ___
 Iup-users mailing list
 Iup-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/iup-users

 
 
 
 --
 
 
 
 ___
 Iup-users mailing list
 Iup-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/iup-users
 


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] Integrating Iup with poll(2) based message loop

2015-07-27 Thread Jörg F. Wittenberger
Am 25.07.2015 um 16:24 schrieb Nodir Temirkhodjaev:
 The best thing I could hope for would be if I could ask Iup for a file
 descriptor to listen on.  Whenever data is ready to read on this fd, I
 would know that Iup wants to become active and I should call the stepper
 until it eat up all this input.
 
 We need new global attribute (maybe XSOCKETFD),
 which will contain result of ConnectionNumber(iupmot_display).

Alike.

But this one would only work for Motif, wouldn't it?



--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] Integrating Iup with poll(2) based message loop

2015-07-27 Thread Jörg F. Wittenberger
Am 25.07.2015 um 16:02 schrieb Antonio Scuri:
  Never used poll before, but if you what to block system execution then I
 suggest you to do it in another thread.

I had a look at the Iup code.  Seems that supporting such an interface
is not as easy as I imagined.

  IupTimer will not work if the main/step functions are not being called.

Yes.  I did call them.  My problem is: when to call the single step
function.  Inside the timer I had problems.  Somehow it just did not do
anything.  Seems I must always return into the main loop to see any
progress?

   If you could call pool function inside a loop with a short wait time,
 then inside that loop call IupLoopStep and the system will be responsive.

That's the busy loop I wrote and rewrote.  It works, but it does not
work well.  Too much system load or not responsive.

What I could do would be to run IUP in one thread and the polling in
another.

But then, how would I communicate from the polling thread to IUP?  I'm
fairly certain that just calling IUP functions would ran havoc.  I'd
need to pause the IUP thread until the polling thread is done calling
IUP functions.

To do so, I'd again end up with a thread in a busy loop calling
IupLoopStep and then pausing for a while.  Possible, but dissatisfying.
 I'm going to do so, but first I want to be certain that I'm not
overlooking some better way.

Thanks

/Jörg

 
 Best,
 Scuri
 
 
 
 On Sat, Jul 25, 2015 at 5:54 AM, Jörg F. Wittenberger 
 joerg.wittenber...@softeyes.net wrote:
 
 Hi Antonio  all,

 these days I wrote, changed, rewrote, modified etc. an ugly piece of
 code.  A workaround for me not knowing how to integrate Iup with a
 poll(2) based message loop.

 All I could come up with where variations of a busy loop.  And thus I
 ended up with two IupVal controls to trade responsiveness for CPU load.

 I'm seeing IupTimer as the intended thing to use here.  Thus the
 application is essentially only running in the timer callback.

 This is mostly ok.  Except it is not.  The problem is: the message loop
 wants to sit in poll().  If it does not, then i/o is delayed until the
 next check.

 Therefore the app feels sluggish, since it does not react to i/o in
 time.  (Except for very short timer periods.)

 Worse the situation becomes if there is a lot of fast, local i/o going
 on; like when accessing a database.  I've seen this timer becoming the
 bottleneck.

 The alternative is to frequently call IupMainLoopStep.  This too results
 in an unacceptable high load.  Also it seem not to really work from the
 timer in all cases.


 So what would be the solution?

 The best thing I could hope for would be if I could ask Iup for a file
 descriptor to listen on.  Whenever data is ready to read on this fd, I
 would know that Iup wants to become active and I should call the stepper
 until it eat up all this input.

 I guess this would not be all to hard to implement at the Iup side.

 But maybe there is a better solution I don't see?

 Thanks

 /Jörg


 --
 ___
 Iup-users mailing list
 Iup-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/iup-users

 
 
 
 --
 
 
 
 ___
 Iup-users mailing list
 Iup-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/iup-users
 


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] Two problems with matrix formatting.

2015-07-27 Thread Jörg F. Wittenberger
Am 25.07.2015 um 16:08 schrieb Antonio Scuri:
 A) the problem is not alignment, but height of the line. Set the HEIGHTn
 attribute for the lines that have text with multiple lines.

If my understanding the documentation is correct, than not giving of
those attributes, I should end up using HEIGHTDEF.  Thus one line.
That's actually what I want.  The idea was to see just the first line.
Seems I'm seeing one line worth around the middle.

 B) the matrix configuration could cause that effect. Which attributes (not
 cell values) of the matrix are you using.

expand: yes, limitexpand: yes, numlin: the number of lines in the
matrix, numcol: 11, cursor ARROW, readonly: yes.

ALIGNMENT1... ALIGNMENT3: ALEFT
FONT*:2 and FONT*:3 :  Monospace, 10
WITDH1 ...WIDTH11 : set to appropriate width for the column range 4..150

Thant's it.

 
 Scuri
 
 
 On Sat, Jul 25, 2015 at 5:15 AM, Jörg F. Wittenberger 
 joerg.wittenber...@softeyes.net wrote:
 
 Hi,

 I have two problems with matrix formatting.

 A) There is an attribute to control the horizontal alignment of matrix
 cells.  But I did not find the equivalent for vertical alignment.  The
 attached MultilineProblem.png shows how horrible content with embeded
 newlines ends up.  (Here an excerpt of a sqlite_master table.)

 I should be able to work around this by cutting the matrix content on
 the first newline, or replace newlines with spaces.  Though this looks
 would need to distinguish between actual content and content on display
 in the matrix.  Thus complicating the app logic quite a bit.

 Is there any better solution?

 B) Worse is the behavior when a matrix horizontally exceeds size of the
 window, but not vertically.  Iup correctly adds a horizontal scrollbar.
  However the scrollbar obstructs the last line of the matrix.  The only
 way (I found) to view this data is to resize the window.  (Which may be
 impossible for large enough a matrix.)

 I'm not sure what the right thing to do would be.  Adding a vertical
 scrollbar is certainly at least required if the matrix would also exceed
 the vertical window size.  Otherwise it might be wiser to simply try to
 recalculate the layout and increase the matrix's height.

 See the second attachment MatrixMissingVScroll

 Best

 /Jörg


 --

 ___
 Iup-users mailing list
 Iup-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/iup-users


 
 
 
 --
 
 
 
 ___
 Iup-users mailing list
 Iup-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/iup-users
 


--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


[Iup-users] Two problems with matrix formatting.

2015-07-25 Thread Jörg F. Wittenberger
Hi,

I have two problems with matrix formatting.

A) There is an attribute to control the horizontal alignment of matrix
cells.  But I did not find the equivalent for vertical alignment.  The
attached MultilineProblem.png shows how horrible content with embeded
newlines ends up.  (Here an excerpt of a sqlite_master table.)

I should be able to work around this by cutting the matrix content on
the first newline, or replace newlines with spaces.  Though this looks
would need to distinguish between actual content and content on display
in the matrix.  Thus complicating the app logic quite a bit.

Is there any better solution?

B) Worse is the behavior when a matrix horizontally exceeds size of the
window, but not vertically.  Iup correctly adds a horizontal scrollbar.
 However the scrollbar obstructs the last line of the matrix.  The only
way (I found) to view this data is to resize the window.  (Which may be
impossible for large enough a matrix.)

I'm not sure what the right thing to do would be.  Adding a vertical
scrollbar is certainly at least required if the matrix would also exceed
the vertical window size.  Otherwise it might be wiser to simply try to
recalculate the layout and increase the matrix's height.

See the second attachment MatrixMissingVScroll

Best

/Jörg
--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


[Iup-users] Integrating Iup with poll(2) based message loop

2015-07-25 Thread Jörg F. Wittenberger
Hi Antonio  all,

these days I wrote, changed, rewrote, modified etc. an ugly piece of
code.  A workaround for me not knowing how to integrate Iup with a
poll(2) based message loop.

All I could come up with where variations of a busy loop.  And thus I
ended up with two IupVal controls to trade responsiveness for CPU load.

I'm seeing IupTimer as the intended thing to use here.  Thus the
application is essentially only running in the timer callback.

This is mostly ok.  Except it is not.  The problem is: the message loop
wants to sit in poll().  If it does not, then i/o is delayed until the
next check.

Therefore the app feels sluggish, since it does not react to i/o in
time.  (Except for very short timer periods.)

Worse the situation becomes if there is a lot of fast, local i/o going
on; like when accessing a database.  I've seen this timer becoming the
bottleneck.

The alternative is to frequently call IupMainLoopStep.  This too results
in an unacceptable high load.  Also it seem not to really work from the
timer in all cases.


So what would be the solution?

The best thing I could hope for would be if I could ask Iup for a file
descriptor to listen on.  Whenever data is ready to read on this fd, I
would know that Iup wants to become active and I should call the stepper
until it eat up all this input.

I guess this would not be all to hard to implement at the Iup side.

But maybe there is a better solution I don't see?

Thanks

/Jörg

--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


Re: [Iup-users] IupProgressDlg with IupPopup?

2015-07-16 Thread Jörg F. Wittenberger
Just a warning.  I observed that forking a process while iup is running
is prone to error.  So I forked one child early on to process async
stuff and use nanomsg to talk to it.  Further forks are handled by that
child.  Much safer to use.

Am 14.07.2015 um 17:38 schrieb Antonio Scuri:
   It could be something related with your fork, because in C, execution
 returns after calling IupPopup always.
 
 Best,
 Scuri
 Em 14/07/2015 12:20, Eric Wing ewmail...@gmail.com escreveu:
 
 On 7/14/15, Antonio Scuri sc...@tecgraf.puc-rio.br wrote:
  That's the normal behavior of IupPopup. It blocks execution until the
 modal dialog is closed. The progress dialog is a regular IupDialog so,
 yes,
 it can be used with IupShow and IupPopup.

 Best,
 Scuri


 Hmmm, I don't think that's what I'm seeing. So in this function that
 sets up everything, I'm also setting up an IupTimer. I'm actually
 fork/exec-ing a process and using the timer to monitor when it is done
 (at which point I destroy the progress dialog).

 The timer callbacks are happening and it doesn't look like the
 execution ever goes back to where I invoked IupPopup.

 Is this cause for concern?

 Thanks,
 Eric


 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 Iup-users mailing list
 Iup-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/iup-users


 
 
 
 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 
 
 
 ___
 Iup-users mailing list
 Iup-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/iup-users
 


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users


[Iup-users] GridBox slowness and more - Was: Re: Can I get my labels and fields to vertically ACENTER in an hBox?

2015-07-10 Thread Jörg F. Wittenberger
Am 10.07.2015 um 14:52 schrieb Antonio Scuri:
  Hi Jörg,
 
   Please start a new thread, instead of replying an existing one to ask
 different questions. Or the answers will get mix up, and it will be harder
 from me to process them all.

Sorry.  Done.  I felt it being related.

   About the original thread
 ...
   About the GridBox, that is not normal. GridBox is just a combination of
 Vbox and Hbox algorithms. But it is a relatively new control, so maybe
 there is a bug that I didn't know of.

Ah, OK.  That explains it.  After I sent the message I learned that
matrixex != matrix ;-) and tried the same thing as a matrix.
Reasonably responsive.  So maybe that's showing that LaTeX alike
algorithms have their cost.  I shall be careful when feeding many cells
into GridBox.  (Maybe it's worth to note this in the docs.  GridBox
looks simple - that's cool - but may be computationally expensive.)

 Have you used other boxes to check if they have the same behavior?

Sort of.  I'm new.  Everything else I tried so far is about as
responsive as I'd expect it to be from experience.

 Is it Lua or C? Can you send me a sample code?

Assume C.  That's what it boils down to eventually.  A single pthread
running C code.

For the pedantic, that's a bit superficial.  It's neither C or Lua what
I actually wrote.  It's Chicken Scheme.  I started here:
http://wiki.call-cc.org/iup-tutor
and ended up calling iup the second best thing since sliced bread (or
something alike).

   About MatrixEx I notice that I forgot to add it to the Makefile in the
 iup root folder. Just go to the srcmatrixex folder and type make.

Thanks.  Will do.

First let me see why the hell those non-modal dialogs appear to be
problematic.  (But I wouldn't be surprised if the problem's reason turns
out to be looking at my screen.)

Best

/Jörg


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users