freenode/#clim - IRC Chatlog
Search
20:50:09
jackdaniel
if you look for "traditional" toolkits like this I think that ltk is better suited, I've written a few projects in it and it matches the common gui practices
20:50:37
jackdaniel
writing tutorial in clim which does not teach clim doesn't sound very useful. either way, once again, good night
20:50:51
krwq
jackdaniel: I do want to use presentations and all stuff clim provides but it's easier to start with something which I know how it works vs something completely new not found in other toolkits
20:54:27
krwq
it's not only about what I can do with stuff, it's also about how quickly I can productively use clim
20:55:51
krwq
so file selection, button, message box (or some other alernative solution) etc would be a better start than presentations and other stuff which I don't know what to do with until I read it all
20:57:30
scymtym
i think a tutorial focusing on such things would put newcomers on a suboptimal trajectory
21:00:04
krwq
I just don't particularly find text based list with `*` showing current element controllable with manually typed commands too appealing
21:00:34
krwq
also the commands for some reason don't match the names I've used, they just somehow got some magically generated nicer names
21:02:42
krwq
I get that it probably might be better path if you want to become an expert but I don't think it's best example for newbies
21:02:53
scymtym
if you command name is com-do-something, the user will see "Do Something" unless you supply a name with the :name option
21:04:05
krwq
scymtym: https://common-lisp.net/project/mcclim/static/documents/mcclim.pdf page 18 of pdf (or page 13 printed in the right top corner)
21:04:07
scymtym
:name nil -> not invocable by name, :name t -> invocable via auto generated name, :name STRING -> invocable via STRING
21:04:49
krwq
scymtym: when I C-c C-d C-d on the define-superapp-command I don't see any doc so it's not particularly easy to know what to even search for in the spec
21:05:27
krwq
scymtym: might be worth to either improve this or at least show newbies how to use the spec with macros generating macros
21:06:53
scymtym
the alternative would be (clim:define-command (com-foo :name WHATEVER :command-table superapp) …)
21:09:25
krwq
also this part of the tutorial is WTF: (format *standard-input* "~a" argument) - no clue how that even works
21:16:13
scymtym
no, if the value of *standard-input* is an interactor-pane, it is a bidirectional stream
21:17:14
krwq
scymtym: can you instead write to *standard-output* then? If it's bi-directional then presumably it will be bound to the same value?
21:17:59
scymtym
you can write to *STANDARD-OUTPUT*, but as we discussed earlier, that is bound according to a different rule: http://bauhh.dyndns.org:8000/clim-spec/28-3.html#_1496
21:18:49
scymtym
if your frame has an application-pane and an interactor-pane, *STANDARD-OUTPUT* is bound to the former, *STANDARD-INPUT* is bound to the latter (by default, you can customize this)
21:20:27
krwq
scymtym: makes sense after you explained it but when I read the tutorial I was scratching my head when I saw that and eventually I just kept going hoping it will be explained
21:26:52
scymtym
krwq: mostly by looking at the example, i think. i don't remember exactly. but i wasn't in a hurry
21:28:00
krwq
I'm having motivational issues because I came for "UI which works everywhere and is easy to plug in everywhere" and so far cannot make any UI which is reasonably easy to use (i.e. like menus where I need to hold the mouse button etc: yes I know fix is pending but still)
21:29:21
krwq
scymtym: fortunatelly I'm not super in a hurry but will be disappointed if I spend longer period of time and won't be able to plug that into the website
21:31:08
scymtym
i see. gtk has the same capability, is a traditional toolkit and has CL bindings. maybe that would be a better fit?
21:31:10
krwq
scymtym: that's my end goal - just want to write UI which works natively in the browser - but not meant for being public (so basically ignore all security problems)
21:31:50
krwq
scymtym: for now I'm fine with native GUI but ultimately I'd like the HTML to be generated
21:32:14
scymtym
in-browser clim will not involve any web frameworks. it will server a single static HTML file and a bit of javascript once, then only talk trough a websocket
21:32:26
krwq
scymtym: btw is there a way to pass pane size (or :geometry) as :max or something? I work with stumpwm and don't necessarily want to pass size all the time
21:34:53
krwq
scymtym: when I work with stumpwm it currently shows for a second as 640x480 and then after a second it auto-resizes correctly
21:36:01
krwq
scymtym: basically what I want is to be able to pass (:geometry :width :max :height :max) in my app instead (:geometry :width 640 :height 480)
21:40:36
krwq
scymtym: actually that would be a cool tutorial to explain how to even write such extension
21:42:30
krwq
scymtym: will need to create github account for that as my employer is not supper happy with me doing non work related stuff on github
21:47:15
krwq
scymtym: I'd prefer that - thank you! I'm trying to recall credentials for the account I made specifically for this purpose long time ago
22:02:20
krwq
scymtym: whichever will do - sounds pretty cool, any chance you could share how that extensibility model works?
22:04:47
krwq
basically if you have any diff or code I can add to my app to have that I'll be happier
22:05:11
scymtym
that just means the function is not in the CLIM standard. i gave you the full name so you can look at it
22:08:57
scymtym
you could add (:geometry :width (clim:graft-width (clim:find-graft)) :height (clim:graft-height (clim:find-graft))) to your application frame definition
22:09:50
krwq
scymtym: way simpler - when you said extension I was thinking that you will need to provide implementation specific way of getting that value first
22:15:43
krwq
scymtym: I see, I think that makes it way more usabe. Btw I think the current version is the easiest to use and perhaps the version with units would work too but :max makes most sense - :maximum would be a bit too verbose IMO for no good reason
22:19:12
krwq
scymtym: everything works as intended. Btw for my first question about the newline character not showing up
22:20:19
krwq
scymtym: so should the bounding region be extended automatically or not? Even when it's not extended it should still be showing up in the example I gavew
22:22:23
scymtym
i think the bounding rectangle of the presentation only includes actual, visible output. but i'm not sure
22:22:54
krwq
scymtym: that makes sense, but what doesn't is that output is currently showing as numbers in one line space separated
22:23:28
krwq
I can see how "~%" can be a bit ambigious or opinionated on how it should behave though
22:24:40
krwq
scymtym: one way or another though I think the new line should be there - unless spec explains this in some more details then I'm interested in the reading
22:24:44
scymtym
change the final command definition to (define-views-command (com-show-person :name t) ((person 'person :gesture :select)) …) to make person presentations clickable
22:29:48
scymtym
the one on page 23 of https://common-lisp.net/project/mcclim/static/documents/mcclim.pdf
22:38:13
krwq
scymtym: the question is not about incremental display - I extended that code so that numbers are presentations of integers
22:39:28
krwq
and was expecting enters to be visible but presentations spanning across the line but saw one liner with all numbers and ~% being ignored for some reason
22:46:42
krwq
scymtym: also prevents people from giving me answers 7h after I already figured out an issue and forgot about it
22:57:41
scymtym
you can do (define-presentation-type my-integer) and use that in the method definition and the PRESENT call
23:08:00
scymtym
did you write (define-presentation-TYPE my-integer ()) and not (define-presentation-METHOD my-integer ())?
23:09:54
scymtym
(define-presentation-method my-integer (object (type integer)) …) -> (define-presentation-method present (object (type my-integer)) …)
23:11:22
scymtym
your example already has PRESENT presentation methods. copy of those but change the specializer of the TYPE parameter to MY-INTEGER
23:12:33
scymtym
did you change (present (car current-element)) -> (present (car current-element) 'my-integer)?
23:21:57
krwq
Per http://www.jucs.org/jucs_14_20/an_implementation_of_clim/jucs_14_20_3358_3369_moore.pdf I should use (defmethod presentation-type-of ((object integer)) 'integer) ?
23:24:13
krwq
nvm, just don't know how can I make my-integer be accepted from places which ask for 'integer
23:31:43
krwq
scymtym: ok works, there is only an issue that the integer is displayed weirdly in the input field
23:32:29
krwq
so presumably 1 arg will need to be specified more in the method - I'll try to figure it out myself
7:17:02
jackdaniel
I'm not very much against passing it over via allow-other keys, just passing a feedback function there would kind of miss the point
7:18:07
jackdaniel
scymtym: are you satisfied with the current inspector state or there are still pending things? If the former I'll take another look over the source code
7:43:03
jackdaniel
I think that being consistent here will be better than introducing magic keywords
7:43:40
jackdaniel
slyrus_ reported the hierarchy tool viewer issue, now I remember that this "ignore-errors" commit I've removed was prompted by this exactly demo
8:44:02
jackdaniel
now, given dnd branch is merged and I've taken care of some lingering issue in ecl, which Sisyphean labour shall I chase now?
8:48:31
jackdaniel
I've liked your joke and I've tried to think about some funny response, but I apparently lack imagination this morning, so please accept my humble unbound slot `witty-answer'