file context/address bar

[spdegabrielle]

Something I miss in applications don't have it is a file context address bar. The 'filename button' is serves the same role, but it hides the path which is undesirable. Having a file context address bar would remove the need for extra wide tabs when you have long filenames or you have two files with the same name but on different paths

e.g. (from xcode)

[rfindler]

The downside of this is that it requires more frame decorations that take space away from the program. Is there a way to do something that would not have that disadvantage?

[spdegabrielle]

How about replacing the filename and (define ...) buttons?or putting it to the right of the language selector. it can be small text - the same size as 'determine language...'

[spdegabrielle]

and remove the check syntax button

[rfindler]

I think we probably don't want to get rid of the define popup thing. But I do like the idea of putting it in the top yellow space.

One thing to be very careful of: the minimum width of the DrRacket window should not increase (or only very little), so the control has to be able to shrink to something very small (perhaps to the size of the current define).

Also, what happens when the toolbar is on the right or the left? Perhaps just keep the current popup directory selector in that case?

[spdegabrielle]

Do you use the (define...) button? I find that When it is small I don’t need it, and when a file is big it is unusable because it is hard to scroll. I was hoping to replace it with a hierlist% explorer like Xcode/atom/VScode etc.

I agree the yellow space at the top is a good beginning, I was thinking a simple text control would be a simple start.

I agree about the width not increasing. I wouldn’t want to make it unusable for someone who only has a small laptop.

Fair point about the toolbar position. Are multiple toolbars an option? Is it time to instrument DrRacket to (optionally) send usage data?

[rfindler]

I don't use the define button much, true. But I do see it being used by others quite a lot. Something that replaced the functionality with something different and better could be okay. But maybe we should focus on a directory-structure control here, since it seems like there is a nice way forward shaping up?

I don't think that a simple text control would be good enough to release.

I think the right thing to do here is to start building a control that is implemented as a class derived from a canvas% object that can be added to the framework. And then it can be used in DrRacket. (I doubt there is something to resuse from the underlying OS's offerings, but maybe checking there to be sure first is a good move.) I've started something that does drawing below. There are lots of other things to do, still, tho (dealing with the sizing issues and figuring out where the path elements are to handle clicking come to mind; there's probably more after that).

I don't think that instrumenting DrRacket to send back UI feedback is part of this issue. There are ton of things to think about if we were to do that. Seems like its own big project!

#lang racket/base
(require racket/gui/base
         racket/class)

(define sep " >> ")

(define dir-control%
  (class canvas%
    (inherit refresh get-dc)

    (define path-elements '())

    (define/public-final (set-path _path)
      (set! path-elements (explode-path (simplify-path _path)))
      (refresh))

    (define/override (on-paint)
      (define dc (get-dc))
      (for/fold ([x 0])
                ([pe (in-list path-elements)])
        (define s
          (cond
            [(relative-path? pe)
             (path-element->string pe)]
            [else
             ;; should be the first one; maybe do this differently?
             (path->string pe)]))
        (define-values (pw ph pd pa) (send dc get-text-extent s))
        (define-values (sw sh sd sa) (send dc get-text-extent sep))
        (cond
          [(= x 0)
           (send dc draw-text s x 0)
           (+ x pw)]
          [else
           (send dc draw-text sep x 0)
           (send dc draw-text s (+ x sw) 0)
           (+ x sw pw)])))

    (super-new)
    (send (get-dc) set-font small-control-font)))


(module+ main
  (define f (new frame% [width 400] [height 100] [label ""]))
  (define c (new dir-control% [parent f]))
  (send c set-path (collection-file-path "base.rkt" "racket"))
  (send f show #t))

[spdegabrielle]

Focus is good.

I've had a play with your code and while I've added a polygon its given me a chance to think about it.

Like any control it needs a callback that is triggered by events;

• it should return the control instance, and the event type.

Should the callback be (lambda (dir-control event dir ) (void)) Where the code in DrR would create an instance and override it to take an action with respect to the dir and the even type;

• 'left-click on folder => 'open file' dialog at that dir
• 'right-click => open context menu?
• 'left-click on file => ?

I've noticed that for most controls the callback is of the form (lambda (dir-control event) (void)), and the user has to send an additional message (send c get-selection) or (send c get-value) - is that a better approach?

I've not thought through how to use the mouse-x value to get the right directory, but I think adding up the text and gap lengths should work. I think the dir returned should be the full path. It just seems easier to do that in the control.

Please let me know your thoughts.

Stephen

`#lang racket/base (require racket/gui/base racket/class)

(define dir-control% (class canvas% (inherit refresh get-dc) (init [callback (λ (ce e) (void))]) (define path-elements '())

(define/public-final (set-path _path)
  (set! path-elements (explode-path (simplify-path _path)))
  (refresh))

(define/override (on-event me)
  (define t (send me get-event-type))
  (when (equal? t 'left-down) (void)))
(define/override (on-paint)
  (define dc (get-dc))
  (define old-brush (send dc get-brush))
  (define old-pen (send dc get-pen))

  (send dc set-brush "silver" 'solid)
  (send dc set-pen "black" 1 'solid)
  
  (for/fold ([x 0])
            ([pe (in-list path-elements)])
    (define (draw-background-segment
             a-dc side-width text-height xoffset yoffset)
      (define height (+ text-height (/ text-height 5)))
      (send a-dc draw-polygon
            (list
             (cons 0 0)
             (cons side-width 0)
             (cons (+ side-width 5) (/ height 2))
             (cons side-width height)
             (cons 0 height)
             (cons 5 (/ height 2)))
            xoffset	 	 	 	 
            yoffset
            ))
    (define s
      (cond
        [(relative-path? pe)
         (path-element->string pe)]
        [else
         ;; should be the first one; maybe do this differently?
         (path->string pe)]))
    (define-values (pw ph pd pa) (send dc get-text-extent s))
    (draw-background-segment dc (+ pw 10) ph x 0)
    (cond
      [(= x 0)
       (send dc draw-text s (+ x 10) 0)
       (+ x 15 pw)]
      [else
       (send dc draw-text s (+ x 10) 0)
       (+ x 15 pw)]))
  (send dc set-brush old-brush)
  (send dc set-pen old-pen))

(super-new [style '()])
(send (get-dc) set-font small-control-font)))

(module+ main (define f (new frame% [width 400] [height 100] [label ""])) (define c (new dir-control% [parent f])) (send c set-path (collection-file-path "base.rkt" "racket")) (send c set-path (current-directory-for-user)) (send f show #t))`

[spdegabrielle]

for reference; https://www.jetbrains.com/help/clion/navigation-bar.html

[jasonhemann]

@spdegabrielle: FWIW I find that I do use the define button in class, and my students seem to do so also. It may be the style of programs we're having them write in this CS1 class are in a medium sized "sweet spot" to especially from search-by-definition. I could imagine wanting to narrow the selection by typing in part of the name, though.