These are chat archives for ipython/ipython

17th
Sep 2014
Damian Avila
@damianavila
Sep 17 2014 00:00
yep... I think so... this happened to me because I try to do weird things... ja ja... what do you think about adding something like that, I mean some method to clear the menu, or better, update the menu?
Thomas Kluyver
@takluyver
Sep 17 2014 00:01
I think that should be fine :)
Jessica B. Hamrick
@jhamrick
Sep 17 2014 01:36
For nbextensions, why is it that if I use IPython.load_extensions(‘nbgrader’), the cell toolbar is not actually loaded if it had previously been selected, but if I use the following, it is?:
    require(["nbextensions/nbgrader"], function (nbgrader) {
        console.log('nbgrader extension loaded');
        nbgrader.load_ipython_extension(IPython.notebook);
    });
(By “not actually loaded”, I mean that the extension is loaded but that the toolbar that is selected by default is just the “no toolbar” setting rather than the one that had previously been used)
Ahh, it has to do with the reference to the notebook object
Ok, I think that explains it, nevermind!
Kyle Kelley
@rgbkrk
Sep 17 2014 02:37
If anyone was playing on that demo server, I'm tearing it down and building a new one (that was on my build server)
Jonathan Frederic
@jdfreder
Sep 17 2014 02:59
I was playing with it earlier
but nothing more than a tester notebook
Min RK
@minrk
Sep 17 2014 03:04
@jhamrick
might be an async issue
Jessica B. Hamrick
@jhamrick
Sep 17 2014 03:04
Yeah I think indirectly it was
The extension was being loaded after the notebook was, and register_preset wasn’t being passed a notebook object, so activate_preset never got called
Matthias Bussonnier
@Carreau
Sep 17 2014 15:09
how can IPython got 17k commits in 3 weeks ?
git log --oneline 3beb4de..3c3af1b| wc -l
git show 3beb4de
Date: Fri Aug 22 12:50:33 2014 -0700
?
@rgbkrk any idea ?
that's an average of 33 comits/hours non stop !
Damian Avila
@damianavila
Sep 17 2014 15:18
wow... really?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 15:19
it is pretty amazing
is it that many backlogged PRs got merged?
Matthias Bussonnier
@Carreau
Sep 17 2014 15:21
Probably but I find it hard to believe
I'm more into a git bug.
yep 17189 is the total number of commit in IPython history.
Damian Avila
@damianavila
Sep 17 2014 15:27
Is there any easy way to recreate a clean vanilla .ipython folder? I mean the same you get from a totally clean installation?
Matthias Bussonnier
@Carreau
Sep 17 2014 15:29
yes, reclone :-)
Kyle Kelley
@rgbkrk
Sep 17 2014 15:29
That's weird. Did someone rebase master?
Matthias Bussonnier
@Carreau
Sep 17 2014 15:30
my git find that ipython/ipython@3beb4de in the first commit of IPython, date from 2014, but has been done bere one commit of 2005
its fine on github aparently.
can one of you try the comands I did above ?
My log graph look like:
| |     backends and the OO matplotlib API.
| |
| * commit b100d4426001d91a4f11ae0ff9dae53a55e7bc9e
| | Author: tzanko <>
| | Date:   Sun Jul 17 01:03:15 2005 +0000
| |
| |     Add ChangeLog symlink, sync up SVN with my local tree (minimal changes), to
| |     start new work off SVN.
| |
| * commit 6f629fcc23ba63342548f61cc7307eeef4f55799
|   Author: fperez <>
|   Date:   Wed Jul 6 17:52:32 2005 +0000
|
|       Reorganized the directory for ipython/ to have its own dir, which is a bit
|       more consistent with the SVN book recommended layout.
|
* commit 3beb4de55409301adf56327b1229dc80036f6cb0
  Author: Jonathan Frederic <jdfreder@calpoly.edu>
  Date:   Fri Aug 22 12:50:33 2014 -0700

      Merge pull request #5897 from ellisonbg/notebook-docs

      Major rewrite of notebook based documentation/examples
Kyle Kelley
@rgbkrk
Sep 17 2014 15:33
I'm about to get on the road, so I won't be able to check
Matthias Bussonnier
@Carreau
Sep 17 2014 15:33
looks like jdfreder want to steel fperez works ! :-) (not at mentionning not to wake them up)
have good trip. C U later
nah, just local git. works fine on my server
Jonathan Frederic
@jdfreder
Sep 17 2014 15:58
I'm confused, that's a commit I made in PR #5897 .
ahhh
it was just a local problem?
Fernando Perez
@fperez
Sep 17 2014 16:50
Hey, has anyone seen these errors?
[W 140917 08:48:11 zmqhandlers:167] WebSocket ping timeout after 18232979 ms.
[W 140917 08:48:11 zmqhandlers:167] WebSocket ping timeout after 18232519 ms.
I had a bunch of kernels open, put my laptop to sleep, and woke it up to this mess. Lost all of them...
Thomas Kluyver
@takluyver
Sep 17 2014 16:50
I think that's a known bug
Fernando Perez
@fperez
Sep 17 2014 16:50
Do you know what triggers it?
I'd never seen it
Thomas Kluyver
@takluyver
Sep 17 2014 16:51
we only added websocket pings fairly recently
I thought @minrk had a fix, but I can't see the PR
Fernando Perez
@fperez
Sep 17 2014 16:51
Is there a way to recover, or should I just restart everything?
Thomas Kluyver
@takluyver
Sep 17 2014 16:51
someone else wrote the fix, Min merged it
#6467
Fernando Perez
@fperez
Sep 17 2014 16:52
I'm at bb121e7 Merge pull request #6483 from jhamrick/fix-heading-anchors
which already has #6467 merged.
So the fix doesn't seem to be fully correct.
Thomas Kluyver
@takluyver
Sep 17 2014 16:53
ah
Fernando Perez
@fperez
Sep 17 2014 16:53
I have to give a talk shortly, is there a way to recover my state or should I just nuke the server and restart?
Min RK
@minrk
Sep 17 2014 16:53
Note that it's just the web socket connections that are dropped.
It didn't kill your kernels, or anything.
Reconnect or refresh the page should do it.
Fernando Perez
@fperez
Sep 17 2014 16:53
ok
let me try
ok, page reload worked. I'll refresh them all...
There were no warnings on the pages at all, I just noticed [*] prompts everywhere I tried to run...
Worth noting this and seeing if a more robust fix is possible.
But I have to shift gears for the MS talk soon. Thx!!
Min RK
@minrk
Sep 17 2014 16:55
There's already an issue for better feedback when web socket connections are lost
Fernando Perez
@fperez
Sep 17 2014 16:55
ok, tx
Min RK
@minrk
Sep 17 2014 16:55
I'll see if I can do it on purpose, then I'll work on a better fix.
Fernando Perez
@fperez
Sep 17 2014 16:55
great
Min RK
@minrk
Sep 17 2014 16:56
If you don't want to worry about if for your talk, set the ping to 0 and it won't check
Fernando Perez
@fperez
Sep 17 2014 16:56
how?
Min RK
@minrk
Sep 17 2014 16:56
tornado_settings['ws_ping_interval'] = 0
sorry, that's webapp_settings['ws_ping_interval'] = 0
Fernando Perez
@fperez
Sep 17 2014 16:57
in which config file?
Min RK
@minrk
Sep 17 2014 16:58
Full line: c.NotebookApp.webapp_settings = {'ws_ping_interval': 0}
in notebook config
Fernando Perez
@fperez
Sep 17 2014 17:02
great, thx
Kyle Kelley
@rgbkrk
Sep 17 2014 20:13
Hey is there a way to install the Julia kernel using the ipython kernelspec command?
On master, that is
Jonathan Frederic
@jdfreder
Sep 17 2014 20:16
idk my bff jill
Kyle Kelley
@rgbkrk
Sep 17 2014 20:17
wat
Jonathan Frederic
@jdfreder
Sep 17 2014 20:19
Sorry, it's a lame meme, I posted a link in danger_zone
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 20:21
Hello

There is no widget registry on the Python side, and to implement instantiation of widgets from the JavaScript side, we probably need one.
What do you think of using a decorator on definition of a widget along the lines of this commit:

SylvainCorlay/ipython@1351f61

@register()
NewWidget(Widget):
   ///

or

@register(key='some_other_key')
NewWidget(Widget):
   ///

if you don't want to use the model name as key

Jonathan Frederic
@jdfreder
Sep 17 2014 20:23
looking
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 20:25
If you like the general idea, I can add the decoration to all the core ipython widgets and open a PR
Jonathan Frederic
@jdfreder
Sep 17 2014 20:26
I do like that idea, however, the built-in widgets don't need it right?
Their namespace should be enough
Kind of like how we will use require js as a register in the front-end
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 20:27
I don't understand what you mean?
Jonathan Frederic
@jdfreder
Sep 17 2014 20:28
Actually maybe we don't even need a registry
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 20:28
I want to be able to specify a custom key which is not the model name because I have a different widgets using the same _view_name and _model_name .
Jonathan Frederic
@jdfreder
Sep 17 2014 20:28
couldn't we just make the target name stored in the front-end a fully qualified python namespace
?
oh ok
wait
but still, using the python process'es namespace would work
you python instances would have to be accessible though
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 20:30
Motivation 1: Js to Python instantiation
Motivation 2 : drag-drop gui building. I need a list of all the widgets.
meaning, only the registered widgets
Jonathan Frederic
@jdfreder
Sep 17 2014 20:30
Ahh
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 20:30
works for both custom and core widgets
Jonathan Frederic
@jdfreder
Sep 17 2014 20:30
motivation 2 needs a registry
you're right
hmm
yeah decorators are nice
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 20:31
ping @jasongrout
OK, I will open a PR.
Jonathan Frederic
@jdfreder
Sep 17 2014 20:31
Does the PR already have the logic to open the widgets from the front-end?
Or is it just the registry?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 20:32
just the registry
I don't want to build too much upon the assumption that you will accept a given change upstream.
btw, any updates on the bulk_change pr? are we decided on on_atomic_change ?
Jonathan Frederic
@jdfreder
Sep 17 2014 20:40
I like on_atomic_change
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 20:41
ok, I will push that.
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 20:47

the widget registry could simply be a key: widget_class as now,
or

key: {
    class: widget_class, 
    metadata: {}
}

to allow for some granularity on the registry.

any preference?
Jonathan Frederic
@jdfreder
Sep 17 2014 20:55
I'm not sure I follow, in what case would you want metadata?
It seems the only thing you'd ever need is the key, or target_name, or what ever we decide to call it
can you give an example of why you'd need to store more information than that?
and also why it wouldn't make sense to have a separate key/value for that information?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 20:59
Absolutely. It is just a choice of where to put that information.
Jonathan Frederic
@jdfreder
Sep 17 2014 20:59
Oh ok
yeah I think I'd prefer the first then
and if we find we need to store more information than a single string, then add separate keys for that later
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:00
Here is the core registry.
{'AccordionView': IPython.html.widgets.widget_selectioncontainer.Accordion,
 'BoxView': IPython.html.widgets.widget_box.Box,
 'ButtonView': IPython.html.widgets.widget_button.Button,
 'CheckboxView': IPython.html.widgets.widget_bool.Checkbox,
 'DropdownView': IPython.html.widgets.widget_selection.Dropdown,
 'FlexBoxView': IPython.html.widgets.widget_box.FlexBox,
 'FloatSliderView': IPython.html.widgets.widget_float.FloatRangeSlider,
 'FloatTextView': IPython.html.widgets.widget_float.BoundedFloatText,
 'HTMLView': IPython.html.widgets.widget_string.HTML,
 'ImageView': IPython.html.widgets.widget_image.Image,
 'IntSliderView': IPython.html.widgets.widget_int.IntRangeSlider,
 'IntTextView': IPython.html.widgets.widget_int.BoundedIntText,
 'LatexView': IPython.html.widgets.widget_string.Latex,
 'PopupView': IPython.html.widgets.widget_box.Popup,
 'ProgressView': IPython.html.widgets.widget_int.IntProgress,
 'RadioButtonsView': IPython.html.widgets.widget_selection.RadioButtons,
 'SelectView': IPython.html.widgets.widget_selection.Select,
 'TabView': IPython.html.widgets.widget_selectioncontainer.Tab,
 'TextView': IPython.html.widgets.widget_string.Text,
 'TextareaView': IPython.html.widgets.widget_string.Textarea,
 'ToggleButtonView': IPython.html.widgets.widget_bool.ToggleButton,
 'ToggleButtonsView': IPython.html.widgets.widget_selection.ToggleButtons,
 'WidgetView': IPython.html.widgets.widget_bool._Bool}
Jonathan Frederic
@jdfreder
Sep 17 2014 21:00
mmmm, why *View?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:00
because it is there. I can strip it
Jonathan Frederic
@jdfreder
Sep 17 2014 21:00
Why not Accordion: Accordion
ah haha
ok yeah
I would strip it
Let me make sure I understand
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:05
I will also be using this registry to also register all my custom widgets.
Jonathan Frederic
@jdfreder
Sep 17 2014 21:05

So in JS, in the ButtonView's declaration, you'd have something like this:

key: 'Button',

and in Python, where the registry is instanciated, you'd have something like this:

'Button': IPython.html.widgets.Button,

then in JS if you wanted to construct a button, you'd do something like this:

IPython.notebook.kernel.widget_manager.create('ButtonView')?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:06
well, that is where the 'View' suffix is really to be removed.
I was thinking of metadata to give information like categorizing the widgets
Input, control, etc
for Motivation 2
we could keep it empty for now
Jonathan Frederic
@jdfreder
Sep 17 2014 21:09
So I just want to make sure I understand the steps that would happen creating an instance of a widget in JS
  • Create model and view
  • Create comm, hook comm up to model
  • Send message over the comm with the key (i.e. "Button")
  • Back-end receives key and looks in registry, finds ButtonWidget and creates an instance of it and hooks it up to the comm.
Is that what you were thinking of?
Because there is another way you could do it too
Of course this way would be asynchronous:
  • Send message to back-end to create the widget for you.
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:14
That is pretty much what I was thinking of
Jonathan Frederic
@jdfreder
Sep 17 2014 21:14
The first one?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:14
Yes.
I have used the second one already
but in the context of a sort of container receiving the message and creating a new child.
in any case, the registry is useful for motivation 2
and the metadata could be as well.
Jonathan Frederic
@jdfreder
Sep 17 2014 21:20
I'm still not sure I agree that the metadata belongs in master
I'd think it'd make more sense to just store any additional data you need to store with the widget definitions themselves
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:22
I am not sure either what would be in it.
but not having dictionary values would prevent us from encapsulating any other info in the future
we could leave it empty initially, let people do what they want with it at first, and come back when we know what it is useful for
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:28
it gives room for extension
Jonathan Frederic
@jdfreder
Sep 17 2014 21:39
But can't you add that kind of information already by just appending it to the class? This kind of idea should work both in Python and JS, right? :
# IPython's code
registry = {
    'Button': IPython.html.widgets.Button,
}

class Button(Widget):
    pass # Stuff here...

# Sylvain's code:
Button.custom_info = {}
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:40
Yeah, you are right.
the other question is what exactly should be used as a key
or should it be a bare set ? (of classes)
Jonathan Frederic
@jdfreder
Sep 17 2014 21:42
A set, as in a python set?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:42
yes
Jonathan Frederic
@jdfreder
Sep 17 2014 21:43
Well the key needs to be serializable, because that's what's sent over the line, right?
key: 'RegisteredBackendWidgetName'
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:43
good point
ok, then I can use the class name as the key
Jonathan Frederic
@jdfreder
Sep 17 2014 21:44
Yup
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 21:45
sorry, got called for something else. back in a few
Jonathan Frederic
@jdfreder
Sep 17 2014 21:45
np ttyl
Jason Grout
@jasongrout
Sep 17 2014 22:07
@jdfreder: why does the box container have a 5-pixel margin? If you have a complicated nesting of boxes, those margins add up pretty quick
Jonathan Frederic
@jdfreder
Sep 17 2014 22:08
I didn't think it did, looking
Jason Grout
@jasongrout
Sep 17 2014 22:09
.widget-box {
    /* The following section sets the style for the invisible div that
    hold widgets and their accompanying labels.

    Looks like this:
    +-----------------------------+
    | widget-box (or similar)     |
    |  +-------+---------------+  |
    |  | Label | Actual Widget |  |
    |  +-------+---------------+  |
    +-----------------------------+
    */
    margin : 5px;

    .start();
    .widget-box();
}
Jonathan Frederic
@jdfreder
Sep 17 2014 22:09
hmmm :frowning:
Jason Grout
@jasongrout
Sep 17 2014 22:10
that picture doesn't reflect reality, I don't think. There is a widget-hbox-single class applied directly around a label/widget pair
Jonathan Frederic
@jdfreder
Sep 17 2014 22:10
That must have been a deliberate choice I made when I was doing the alignment.
I'm sorry I don't remember exactly why I chose 5 px
Jason Grout
@jasongrout
Sep 17 2014 22:11
This picture should be of a widget-hbox-single. The widget-box is applied around the widget-hbox-single.
Jonathan Frederic
@jdfreder
Sep 17 2014 22:11
In the PR that adds easy styling traits, there is a margin trait you can set to 0
Jason Grout
@jasongrout
Sep 17 2014 22:12
I think the default maybe ought to be 0. The Box is used to lay out things vertically, horizontally, etc. They will often be nested deeply, and having a margin on each one adds up fast
Jonathan Frederic
@jdfreder
Sep 17 2014 22:15
Yeah I think that's a good default
I'm worried that the 5px margin is left over from the PR that I did the renaming in
because that class used to be called widget-container
Jason Grout
@jasongrout
Sep 17 2014 22:16
That's also what I was wondering
Jonathan Frederic
@jdfreder
Sep 17 2014 22:16
which I think was more generic than the ContainerWidget
I seem to remember consolidating them into one class
Jason Grout
@jasongrout
Sep 17 2014 22:16
uh oh
Jonathan Frederic
@jdfreder
Sep 17 2014 22:16
because it seemed like that made sense
but looking at it again, it may not
Jason Grout
@jasongrout
Sep 17 2014 22:17
I thought a while ago that the margin wasn't 5px, and I was surprised to see just now that it was.
Jonathan Frederic
@jdfreder
Sep 17 2014 22:17
In the remove/add_class removal PR
I've also been consolidating classes
widget-vbox-single and widget-hbox-single seem to be unecessary
Jason Grout
@jasongrout
Sep 17 2014 22:18
Regardless, the pic above is wrong---that should be the widget-hbox-single class, not the widget-box class. I don't think the widget-box class is ever directly wrapped around the widget elements (but I may be wrong there)
Jonathan Frederic
@jdfreder
Sep 17 2014 22:18
You're right, the picture is wrong
Jason Grout
@jasongrout
Sep 17 2014 22:19
okay; I'll let you make the decision about widget-hbox-single/widget-vbox-single. But I still think the basic Box class should have 0 margins and 0 padding. It should be purely a layout class.
Jonathan Frederic
@jdfreder
Sep 17 2014 22:19
but just because it has the "Label" and "Actual"
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:19
@jdfreder on the add_class, remove_class PR, we had some discussions here on it. I will rport it in the PR tomorrow.
Jason Grout
@jasongrout
Sep 17 2014 22:19
anyways, gotta run.
Jonathan Frederic
@jdfreder
Sep 17 2014 22:19
since views like ButtonView call setelement to set the element
ok ttyl
@SylvainCorlay that would be great!
I really want to move that PR along
it's a thorn in my side
and everyone else who wants to work with/on widgets
it touches a lot of code
I did address @jasongrout 's comments in it
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:21
ok, the idea is that things like width and height should not necessarily be features of the widget itself but determined by the context, like in html
(flexbox and all)
Jonathan Frederic
@jdfreder
Sep 17 2014 22:23
Oh yes, I think Brian mentioned something like that
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:23
For the purpose of applying css transformations, we have a Proxy widget. It is a container with one child that handles styling on its child.
Jonathan Frederic
@jdfreder
Sep 17 2014 22:23
so for Flex widgets you could do .width="flex1" etc right?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:24
what I mean is that Button should not have a width attribute.
You could have a Proxy(Button) that applies attributes to its child
Jonathan Frederic
@jdfreder
Sep 17 2014 22:24
hmmm
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:24
the main widget model for the slider only contains slider content related things
Jonathan Frederic
@jdfreder
Sep 17 2014 22:24
Why? That seems unnecessarily complex. What does it buy you?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:24
the layout / styling is the responsibility of the context, a container or a proxy
or the widget-area
Jonathan Frederic
@jdfreder
Sep 17 2014 22:25
Oh
So you could do Style(Widget1, Widget2(Widget3))
and all 3 child widgets would get the same style?
So Style was traversing ?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:26
For example, I want a floating layout container, and a flex box both containing the same widgets
in the floating layout container, width and height of the children are not property of the children modls
otherwise, it will interfere with the aspect of the widgets in the flex box container
Jonathan Frederic
@jdfreder
Sep 17 2014 22:28
How about allowing both? Both traits, on a per widget basis, and a contextual style like you suggest?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:28
Our proxy stuff was initially meant for something else than styling but could prove useful for css styling
Jonathan Frederic
@jdfreder
Sep 17 2014 22:29
Because it seems like part of the reason for adding basic style traits is just to make a simpler API for the user
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:30
I don't have a strong opinion, and I don't know if this is the way to do it. It is just the result of my thinking when I was trying to deal with layouts.
Jonathan Frederic
@jdfreder
Sep 17 2014 22:30
I think it's a very good idea
and I think it does make sense to do it
but I'm thinking it makes sense to do both if possible
where local style traits would override values set contextually
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:31
I don't have specific remarks on the implementation,, mostly this choice of making the styling part of the widget
Jonathan Frederic
@jdfreder
Sep 17 2014 22:31
just like specificty in CSS
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:33
OK, we will see if we can extract something meaningful that would naturally be contributed upstream.
Jason Grout
@jasongrout
Sep 17 2014 22:34
@jdfreder (sorry, haven't left yet)...That .widget-box less above calls .widget-box() inside itself. A bit redundant, no? (though maybe I'm not understanding the less)
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:38
In the end, the layout / styling using proxies could be a declarative pure python way of creating layouts.
gui = VBox([ HBox([Miniature(wid, width=50, height=50, aspect_ratio=True) for wid in list1]),
            HBox([list1[0], Slider2])])
Jason Grout
@jasongrout
Sep 17 2014 22:42
gui = VBox([ HBox([CSS(wid, width=50, height=50, aspect_ratio=True) for wid in list1]),
            HBox([list1[0], Slider2])])
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:42
yeah, not being very specify about the syntax
I hear abstraction leaking
Jason Grout
@jasongrout
Sep 17 2014 22:43
ParseLayout("""
VBox:
    HBox:
        CSS: width=50, height=50, aspect_ratio=True, wid
    HBox:
        list1[0]
        Slider2
""")
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 22:43
enaml!
Jonathan Frederic
@jdfreder
Sep 17 2014 22:44
lol
Jason Grout
@jasongrout
Sep 17 2014 22:44
Yeah, you're right about abstraction leaking...
So how would you do it without declarations?
```python
```python
grrr
```python
wid=MyWidget()
c = CSS(wid)
c.width=40
c.height=50
display(c)
as opposed to, say:
wid = MyWidget()
wid.css.update(width=40, height=50)
display(wid)
for a CSS dict added to everything
Brian E. Granger
@ellisonbg
Sep 17 2014 22:57
```python
print "This is a test"
With the new CSS traitlets, why not just build a dict of values and then pass them into all the widgets you want to style that way?
mystyle=dict(width=50, height=100)
h1 = HBox(..., **mystyle)
h2 = HBox(..., **mystyle)
Brian E. Granger
@ellisonbg
Sep 17 2014 23:02
80/20 solution
well more like 100/0 - 100% of the feature with 0 percent of the complexity
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 23:03
I understand styling and layout is a view-specific thing, and the widget attributes as a model thing
I could want different views of the same widget, displayed in different context to have different sizing / layout
CSS, HBox, VBox, the widget area, some proxies like Miniature, or floating layout are different contexts setting the layout and the styling of the content.
Brian E. Granger
@ellisonbg
Sep 17 2014 23:05
But to get we would definitely have to split the model+view in python
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 23:05
why?
Jonathan Frederic
@jdfreder
Sep 17 2014 23:06
@ellisonbg that's already given to us with CSS
Brian E. Granger
@ellisonbg
Sep 17 2014 23:06
"different views of the same widget"
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 23:06
display(FlexBox(wid), Miniature(wid, width=30, height=30))
Jonathan Frederic
@jdfreder
Sep 17 2014 23:06
in the current PR
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 23:07
In what I propose, there is no reference to the view in the Python
just that when I call display(w) twice, I get two views, and a third one is w is in a widget container.
Brian E. Granger
@ellisonbg
Sep 17 2014 23:08
Is the proposal written out somewhere?
Sylvain Corlay
@SylvainCorlay
Sep 17 2014 23:08
No, I wanted to make a PR tomorrow, but we started discussing here
pretty long thread
The transform widget that you saw the other day used that.