Moose-dev January 2012

moose-dev@list.inf.unibe.ch

27 participants
137 discussions

by Alexandre Bergel

Thanks Veronica! This is now in Mondrian 2.142 2.143 is now open for contribution Cheers, Alexandre On 3 Jan 2012, at 10:45, Veronica Isabel Uquillas Gomez wrote: > Hi Alex, > > It seems that i forgot to publish this addition (included an example). > > > Name: Mondrian-Pharo-Morphic-VeronicaUquillas.31 > Author: VeronicaUquillas > Time: 3 January 2012, 2:43:11 pm > UUID: 2ce71ab8-8611-4160-a8b7-a01e57ae7e9b > Ancestors: Mondrian-Pharo-Morphic-AlexandreBergel.30 > > edges can also show a popup view > > > Cheers, > Veronica > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years, 3 months

Re: Issue 322 in moose-technology: Add status bar to MOBrowser and MOEasel

by moose-technology＠googlecode.com

Updates: Labels: -Milestone-4.2 Comment #9 on issue 322 by tudor.gi...(a)gmail.com: Add status bar to MOBrowser and MOEasel http://code.google.com/p/moose-technology/issues/detail?id=322 (No comment was entered for this change.)

12 years, 3 months

Issue 499 in moose-technology: Port & transmission in Mondrian

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Mondrian New issue 499 by alexandr...(a)gmail.com: Port & transmission in Mondrian http://code.google.com/p/moose-technology/issues/detail?id=499 Hi Alex, -=-=-=-=-= Previous discussion: What we did in Glamour was to attach to each Presentation a kind of default interaction. In your example, I would make #mouseEnter, #mouseClick ... default ports that are populated when the corresponding interactions happen on a graph element. Then of course, these ports will belong to graph elements. Like this transmissions are created between the ports of a graph element. Perhaps there will also be a need to identify graph elements by name so that you can refer to them from outside the context of a script. -=-=-=-=-= Previous discussion: Why not having ports that belong to an interaction instead? Consider the following script: view nodes: (1 to: 1000). Figure selection will imply a transmission between the root and each of these nodes. It could be a single transmission between 'root interaction' and the unique interaction of the nodes? -=-=-=-=-= Doru answer: At least two reasons. First, the ports are not just for transmitting information, but ports also allow you to store arbitrary values that model the graph element, and thus you can model the state of a visualization (including side-effects). Second, using ports you will be able to let the shape populate ports by default without writing any explicit interaction (only write transmission when you want to deal with them). Now, about we can be smart about transmissions and do what we do for shapes: we share the object between multiple graph elements. For this, we will just need a lookup of the origins instead of hardcoding them. Actually in Glamour, we have: GLMTransmission>>originatesAt: aPort and thus, you can have a smart transmission that performs a more complex check by checking if the port is part of any elements from a collection. Like this you will have only one the transmission object. You could write: view nodes: #(1 2 3) labeled: #interestingNodes. view nodes: #(5 6 7) labeled: #otherNodes. view transmitTo: #otherNodes fromAny: #interestingNodes port: #selection. Cheers, Doru

12 years, 3 months

adding checkbox in glamour status bar

by Usman Bhatti

I am trying to add a checkbox in the glamour status bar for allowing user to change the type of interaction with a visualization. I've seen different glamour examples but most are about adding lists, buttons and dropdown lists. My question: Is there an easy way to add a checkbox in the status bar of the GLMTabulator? I have a (not so elegant) solution that allows toggling for the moment. browser := GLMTabulator withStatusbar. browser column: #painting. browser act: [:b | ((b actions at: 1) title includesSubString: 'Provider') ifTrue: [(b actions at: 1) title: 'Client Dependencies'.] ifFalse: [(b actions at: 1) title: 'Provider Dependencies'] ] entitled: 'Client Dependencies'. browser transmit to: #painting; andShow: [ :a | a mondrian view: self view ]. ^ browser thanx Usman

12 years, 3 months

Adding a new partner

by Alexandre Bergel

Hi! Can the following be added to http://www.moosetechnology.org/about/partners Facultad de Ciencias Exactas, Universidad Nacional del Centro de la Provincia de Buenos Aires, Tandil, Argentina http://www.exa.unicen.edu.ar/ Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years, 3 months

Customizing Magritte Morphic Forms

by Sean P. DeNigris

Lukas suggested I repost this here from the Magritte list (http://forum.world.st/Customizing-Magritte-Morphic-Forms-td4251518.html): I'm playing with and already enjoying Magritte after the awesome talk Nick and Esteban gave at ESUG this year. How do I customize Magritte editors in Morphic? Specifically, for the Address example from the Seaside book, I tried: anAddress asMorph addButtons; addWindow; openInWorld. but the fields were really tiny and hid most of the text as you can see below: http://forum.world.st/file/n4251570/PharoScreenshot.2.png Then I tried a standard Morphic approach: | form window | form := anAddress asMorph addButtons. window := SystemWindow new addMorph: form fullFrame: (LayoutFrame fractions: (0@0 corner: 1.0(a)1.0) offsets: (10@10 corner: 10@10)). window openInWorld. but I got "MessageNotUnderstood: MAContainerMorph>>layoutFrame:" -- View this message in context: http://forum.world.st/Customizing-Magritte-Morphic-Forms-tp4251570p4251570.… Sent from the Moose mailing list archive at Nabble.com.

12 years, 3 months

Testing Kumpel

by Felipe González

Hi! I am Felipe González a student from Alexandre Bergel. I would like to understand Kumpel and improve it's overall quality. I will be fully working on it for the next two weeks. Here is what I can see in Kumpel: - There's no documentation in the classes nor the tests classes - Almost all test methods hasn't a proper method category - There's almost no class hierarchy - The next classes doesn't have any tests: KMPProjectBuilderConfig KMPProjectLoader KMPImportSVNCommand PPDateParser KMPFileVersion PPProjectInfoParser KMPProjectLoader KMPProjectBuilderConfig KMPProjectBuilder is the largest class, but it is almost not tested. I would like to improve the coverage of Kumpel. Does it makes sense for you to write tests for this class? Like this, I'll learn about Kumpel and hopefully be able to make a useful contribution :) I will put the result of my work in the repository ss3.gemstone.com/ss/CC6403-2011 I will let you know how it goes. Any suggestion? Regards, Felipe -- Felipe González Martínez Estudiante de Ingeniería Civil en Computación Departamento de Ciencias de la Computación Universidad de Chile

12 years, 3 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev January 2012